July 2012 - glue-wg - lists.ogf.org

flat xml rendering
by david.meredith＠stfc.ac.uk 04 Oct '12

04 Oct '12

Hi all, Following OGF 35 I have produced an updated draft of the XSD: http://tools.ngs.ac.uk/ngstools/glue2proposal/flat.zip This rendering has a 'flat' style and includes the global <Entities> element bag with abstract elements/substitution groups. There are a few choices that still need to be addressed which are highlighted with TODO annotations (please do a search on 'TODO' in glue2_2.xsd). A sample instance document is also provided (glue2_2SampleDoc1.xml). For the purposes of demonstration, there is also a sample XSD (sampleGlue2_2Extension.xsd) that imports the glue2_2.xsd to define new service and endpoint element types. This shows how future profiles could extend the glue XSD in order to define new sub-type specialisations (also see the sample instance doc, sampleGlue2_2ExtensionDoc.xml). I guess the next step is to do another telephone conf to agree/disagree. If possible, i would prefer to do this before spending too much effort on updating the Word doc. Cheers, David ========================== David Meredith Scientific Computing Technology eScience Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith(a)stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.

4 14

AccessMode
by stephen.burke＠stfc.ac.uk 01 Aug '12

01 Aug '12

Hi, Going through the GLUE 2 schema I just noticed that StorageShare has an attribute called AccessMode with type AccessMode_t which doesn't appear to be defined. The text is "An identifier for the type of access and usage allowed for this Share." which doesn't immediately ring any bells. Does anyone know what this was for? Stephen -- Scanned by iCritical.

2 2

Issue with several ServiceTypes, "modal" operation
by Florido Paganelli 05 Jul '12

05 Jul '12

Hi all, I would like to raise what I think is an issue with some ServiceTypes we decided on the last enumeration call long time ago, and I think this list is the correct place as my observation will question the sanity of these open enumerations. So let me briefly set the scenario with an ARC example. An ARC Computing Element (or ARC CE) can be configured to support different clustering systems, or LRMS, and its corresponding Execution Service has a well defined GLUE2 name called org.nordugrid.execution.arex Now, an ARC CE can be configured to act as a gateway for Desktop Grids, by simply using a different LRMS called DGBridge. The CE works exaclty the same way as usual, but will only allow jobs designed for Desktop Grids, discarding or failing all the others. On an operational point of view, GOCDB suggested to use a different ServiceType for the above configuration, namely dg.ARC-CE. So what happens now is, the ARC CE Desktop Grid Gateway publishes org.nordugrid.execution.arex as ServiceType, and GOCDB calls it dg.ARC-CE. I see a consistency problem here. Would be strange to have a GLUE2 ServiceType in GOCDB that is _not_ published by any Resource out there: what happens when a client asks info to GOCDB? it will find a ServiceType that doesn't match any of the data published by the resource it is pointing to. Weird isn't it? When I stumbled upon GLUE2 for the first time I dreamt of an automatic discovery system where ServiceTypes where automatically fetched by some monitoring system that would automatically understand what-is-what by looking at infosystem data. (the repetition of automatic* is intended ;) ) I foresee that such a "modal" setup for a CE or any resource being common in the future, and we have to suggest a sane way of doing these things that comes towards operational needs (like GOCDB) and doesn't make the CE sysadmin job messy (no much manual data adding into a database). Solution 1 would be: for ARC (and gLite and Unicore) to change its ServiceType or add another ComputingService entry to with ServiceType=dg.ARC-CE when operating as a Desktop Grid gateway. In a dream world, this could also allow autodiscovery of Desktop Grid Gateways, which is not done today (the gateway urls are hardcoded in clients) The bad thing about the above is that hides the fact that ARC CE is actually acting exactly the same way as any ARC CE, it's just using a different backend. So Solution 2 would be for monitoring/discovery clients to check ComputingManager to see what kind of LRMS is running behind it. But do all systems use an LRMS to achieve this? this is something we cannot hypothesize. There might be a Solution 3 to this problem, that is, add this "modal operation" info somewhere else. where? OtherInfo? Capability? I have no clue... Some reserved string like OtherInfo=DGGateway in all the CEs serving as gateways... Solution 1 is the easiest one, and gives responsibility to developers to publish relevant information in their renderings if they want to be discovered properly, with little manual intervention from sysadmins. Information clients could filter their searches depending on ServiceTypes. In the ARC case, the changes in the code to have a different ServiceType when operating as a Desktop Grid gateway are trivial. However, we're doing strong coupling between ComputingService and ComputingManager, which I am not sure is sane... So the bottom line is, what is the meaning and the use of ServiceType_t if not summarizing such complex setups? So far we mostly used endpoints for discovery. I think it SHOULD be used to summarize complex setups. I think is a GLUE2 WG task to understand, if not describe and propose, how these values can be used in a nice way. What's your opinion on that? -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

2 3

Open enumeration values for the generic service provider
by stephen.burke＠stfc.ac.uk 04 Jul '12

04 Jul '12

Hi, Prompted by Paul, here's a summary of the enumerated types that can be published by my generic provider (at least as known to me, it may be used to publish other services). Stephen EndpointInterfaceName: org.glite.AMGA org.glite.Argus.PAP org.glite.Argus.PDP org.glite.Argus.PEP bdii_site bdii_top org.glite.ce.Monitor org.lcg.Frontier org.glite.lb.Server MyProxy org.glite.ce.ApplicationPublisher org.lcg.Squid VOBOX org.glite.voms-admin org.glite.voms org.glite.wms.WMProxy For services with only one endpoint type the ServiceType is the same as the EndpointInterfaceName. Otherwise we have: org.glite.Argus VOMS Capabilities: data.access.relational security.authorization security.identitymapping security.credentialstorage security.attributeauthority information.model information.discovery information.monitoring information.logging information.publication executionmanagement.candidatesetgenerator executionmanagement.jobdescription executionmanagement.jobmanager Note that information.publication is new as there didn't seem to be anything suitable: it's for a service which allows information to be added to what is otherwise published. PolicyScheme: org.glite.standard -- Scanned by iCritical.

2 4

Open enumeration values that dCache publishes
by Paul Millar 03 Jul '12

03 Jul '12

Hi, A little while ago (err, perhaps not that recently), Florido Paganelli started an initiative to collect the values currently being published for open-enumeration attributes. This was to populate a list of definitive values; to avoid publishers provide distinct values that have the same (or sufficiently similar) meaning, and to identify and reconcile if this is already happening. Below is a list of open-enumeration values that dCache info-provider can publish. I've grouped the enumerations by entity and written each enumeration value like this: <entity-type>.<attribute>: <enumeration-value> The actual set of values published by any dCache instance will be a subset of this, which depends on configuration, current operating conditions, etc. Cheers, Paul. --- StorageService.Type: org.dcache.storage StorageService.Capability: data.access.flatfiles StorageService.Capability: data.management.storage StorageService.Capability: data.management.transfer StorageService.Capability: data.transfer StorageService.Capability: security.delegation DataStore.Type: disk StorageServiceCapacity.Type: online StorageServiceCapacity.Type: nearline StorageAccessProtocol.Type: xrootd StorageAccessProtocol.Type: file StorageAccessProtocol.Type: dcap StorageAccessProtocol.Type: gsidcap StorageAccessProtocol.Type: ftp StorageAccessProtocol.Type: gsiftp StorageAccessProtocol.Type: gkftp StorageAccessProtocol.Type: http StorageAccessProtocol.Type: https Endpoint.InterfaceName: xroot Endpoint.InterfaceName: file Endpoint.InterfaceName: dcap Endpoint.InterfaceName: gsidcap Endpoint.InterfaceName: ftp Endpoint.InterfaceName: gsiftp Endpoint.InterfaceName: gkftp Endpoint.InterfaceName: http Endpoint.InterfaceName: https Endpoint.InterfaceName: SRM Endpoint.Capability: data.management.storage Endpoint.Capability: data.management.transfer Endpoint.Capability: data.management.transfer Endpoint.Capability: data.transfer AccessPolicy.Scheme: basic MappingPolicy.Scheme: basic StorageShareCapacity.Type: online StorageShareCapacity.Type: installedonline StorageShare.RetentionPolicy: replica StorageShare.RetentionPolicy: custodial

2 1