- glue-wg - lists.ogf.org

Meeting Notes: August 29, 2012
by Shiraz Memon 30 Aug '12

30 Aug '12

Dear WG, The meeting notes from yesterday's meeting (29.08) have been published on our wiki: http://redmine.ogf.org/projects/glue-wg/wiki/29_August_2012 Should you find any errors, please let me know. Cheers, Shiraz -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899<tel:%2B49%202461%2061%206899> Fax: +49 2461 61 6656<tel:%2B49%202461%2061%206656> ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

1 0

EGI TF
by stephen.burke＠stfc.ac.uk 28 Aug '12

28 Aug '12

Hi, There will be an information system workshop during the EGI Technical Forum in Prague (September 20th), and it would be interesting to know how many people on this list will be there. Stephen -- Scanned by iCritical.

3 3

Next Teleconference Meeting
by Shiraz Memon 28 Aug '12

28 Aug '12

Hi all, We will meet tomorrow at 16:30. The details are as follows: Coordinates: : Thursday, May 31, 2012 : 16:30-18:00 Central Europe, 10:30-12:00 AM US Eastern Teleconference and screen sharing: : https://webconf.vc.dfn.de/ogf-glue-wg/ (Adobe Connect) : Login as Guest using your real name Agenda: * progress on xsd schema (flat style) * progress on ldap rendering document * publishing pseudo-standard enumerations * migration from grid-forge to redmine * any other issues? Cheers, Shiraz -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

1 1

ComputingService and Endpoints, a point of view
by Florido Paganelli 28 Aug '12

28 Aug '12

Hi all, I've been thinking about this ComputingService <- exposes -> Endpoints association and if it's possible to do it based on the UML diagrams contained in GFD1.47. (see figures on page 7, 22) I think the UML diagram doesn't clarify what happens to the association <- exposes -> with respect to inheritance when it comes to the specialized classes ComputingService,ComputingEndpoint. What we have is Service <- exposes -> Endpoints ComputingService <- exposes -> ComputingEndpoints Now if we could write this as a piece of object oriented pseudocode, we would have Class Service { // a list of exposed Endpoints Endpoint MyEndpoints } Class ComputingService extends Service { // a list of exposed ComputingEndpoints ComputingEndpoint MyComputingEndpoints } What happens with inheritance wrt <- exposes -> ? I think there can be two implementations for a ComputingService constructor: 1) ComputingService includes the <- exposes -> from Service, that is, an instance of ComputingService would have both MyEndpoints and MyComputingEndpoints: ComputingService( EndpointList someEndpoints , ComputingEndpointList someComputingEndpoints ) { this.MyEndpoints = someEndpoints; this.MyComputingEndpoints = someComputingEndpoints; } 2) ComputingService overrides the <- exposes -> from Service, that is an instance of ComputingService has ComputingService( ComputingEndpointList someComputingEndpoints ) { this.MyEndpoints = someComputingEndpoints } I favour the 1) as it makes possible to have Endpoints inside a ComputingService, that would give better readability and clarity to Endpoints which are NOT ComputingEndpoints. these two implementation are, in my opinion, both possible as UML does not really scope associations with inheritance. What do you think? Which one should we favour? I am really annoyed of calling ComputingEndpoint an Endpoint that has nothing to do with computing! Thanks for your answers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

2 6

Call for the Next Teleconference Meeting
by Shiraz Memon 23 Aug '12

23 Aug '12

Dear WG Members, To finalize the glue schema and the corresponding rendering documents, me and JP would like to invite you for a (~1.5 hrs) meeting, the agenda items will be: * progress on xsd schema (flat style) * progress on ldap rendering document * publishing pseudo-standard enumerations * migration from grid-forge to redmine * any other issues? Please mark your availability under the following doodle link: http://www.doodle.com/pcmk3myur2k763gt Best regards, Shiraz -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899<tel:%2B49%202461%2061%206899> Fax: +49 2461 61 6656<tel:%2B49%202461%2061%206656> ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

1 0

Endpoints and ComputingService, relationships between services. Some thoughs
by Florido Paganelli 20 Aug '12

20 Aug '12

Hi all, I am in the situation that I would like to have a simple Endpoint published within a ComputingService. However, besides UML inheritance might allow this, the hierarchic xsd schema does not allow that, it only allows ComputingEndpoints to be nested within ComputingServices. I don't know it this is good or bad; for you to understand how I got here, I can give you this little problem to solve: Suppose the same machine hosts two RELATED services, that is, one needs the other one for proper functionality. For example a delegation service is needed to submit a job to a job execution service. Is there a way for an information consumer to infer/understand this relationship? Can a client understand that (1) the services are related and (2) that they are running in the same machine just by looking at the GLUE2 records? One might think of associations, but it can easily be shown that they don't solve the problem. We don't really have service-to-service associations, just some kind of hierarchy between services. What do you think? -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

3 12

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