- glue-wg - lists.ogf.org

Status of GLUE 2.0 Specification as regards going public comment
by Sergio Andreozzi 19 May '08

19 May '08

Dear all, this is to inform all of you that we are still in the process of digesting all the feedback that we received about the GLUE 2.0 Spec, WG last call. We are creating a document containing all the feedback and how each individual point was considered as regards the public comment version of the spec. At the moment, we processed 50% of the feedback and we expect to finalize it and send the document to the area directors by tomorrow COB, 20 May. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

Invoking some magic: RDF, VO annotations and Grimoires
by Paul Millar 19 May '08

19 May '08

Hi all, In a round-about way, I (re)discovered a project a friend mentioned a while ago, called "Grimoires": http://twiki.grimoires.org/bin/view/Grimoires/ If you're not familiar with the project, it's basically registry that allows for service discovery, based on UDDI but allowing RDF (i.e., "semantic") annotations by multiple user communities. This should allow different end-user communities to annotate a service in almost any way supported by RDF. Re-reading the page, I was struck by what Stephen said earlier about allowing user-communities to annotate GLUE information. The interesting part comes if all GLUE entities were cast as either a UDDI-registered service or as an annotation of a service. It should be relatively easy for someone with some spare time hands (i.e., not me :) to map GLUE vocab. into RDF and allow GLUE-like publishing of information into a Grimoires server. This would allow end-users to ask some nice queries, combining their "personal" metadata with GLUE information. There's another RDF project that hook into GT4: S-MDS. IIRC, S-MDS maps the MDS information into a SPARQL end-point via some (fairly static) mapping rules. I suspect it could be persuaded to ingest GLUE (in-band via MDS or out-of-band), but 3rd-party annotations would have to be out-of-band (unless they have write-access to MDS). Whereas the Grimoires project seems to be a more integrated approach. Should we make contact with these people to see if they're interested in adopting GLUE as a case-study? It might prove useful if we provide an RDF binding for GLUE. Cheers, Paul.

2 1

v1.3 documentation, please!
by Paul Millar 19 May '08

19 May '08

Hi all, Sorry, this is a bit of rant. I'm in the process overhauling how dCache information is published into GLUE: a complete rewrite of how information is propagated. So I'm looking for definitive information about how to publish Glue through GIP. ... and there's the rub. I can't find any good references for how to provide this information. I've started a dCache wiki page[1] that holds various nuggets of information, but none of them seem complete or authoritative. [1] http://trac.dcache.org/trac.cgi/wiki/GLUE I understand that the current dCache system, is functional through Owen's sterling effort, with various trial-and-error attempts and information conveyed through emails. I'm looking to avoid this process as much as possible; having accurate information would be a good start! First off, the only GLUE v1.3 documentation I could find is from CNAF CVS [2]. The most recent version is "Draft 3---16 Jan 2007". I think Sergio was going to make this the final version, but could this process be clarified? BTW, there's a typo in the StorageArea, UsedNearlineSize description; there are other sections that look somewhat incomplete (e.g., grep for "TO BE ADDED") [2] https://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/*checkout*/v_1_3/spec… Second, I could also find no authoritative source of information on Glue/LDAP binding for v1.3. There are some CNAF notes[3], but these mention, in bold, that "[t]his version is for early evaluation and is not meant to be deployed yet". Can someone say what is incorrect on this page? More importantly, can someone update it so the page is correct? [3] http://glueschema.forge.cnaf.infn.it/SpecV13/LDAP The CNAF notes also mention that certain attributes are "deprecated and their use should be removed from any software". Does this mean info-provides "must" (or "should", or "may", see RFC 2119) refrain from publishing deprecated attributes? For example, should no info-provider be publishing GlueChunkKey anymore? For publishing SRM spaces, I found a *proposal* for how this should be done[4]. Confusingly, this contradicts the GLUE/LDAP notes[3] as it stipulates that "mds-vo-name = local" must be used, whereas the notes state that mds-vo-name has been removed from the DIT; in practise "mds-vo-name = resource" (as a primary document, for feeding into GIP) is what seems to work. [4] https://twiki.cern.ch/twiki/bin/view/LCG/GSSDGLUEProposal Finally, (prodding Laurence) I could not find *any* statement about what format GIP supports as primary input (although I might have missed this). I'd assume this is roughly GLUE v1.3/LDAP, but apparently there's some magic happens with DNs with RDF of "mds-vo-name=resource". Is this (still) true? Is it required? What other mappings and translations are possible? Sorry, I'm sure this info is well known by others, but it doesn't appear to be documented. Can some knowledgable person take on responsibility for ensuring this is all properly documented? Cheers, Paul.

7 18

GLUE 2.0 Specification - draft 41 - Working Group Last Call
by Sergio Andreozzi 16 May '08

16 May '08

Dear all, in our plan, we have the important milestone of presenting for the coming OGF a public comment version GLUE 2.0 in order to achieve a broader exposure of our work and receive a broader review. Starting from the GLUE 2.0 specification available at the end of April (which is the result of a long series of teleconferences and email exchange by many partners) we refactored the document to be consistent and we completed all its parts. The updated renderings of the conceptual model to the XML Schema/LDAP/relational concrete data models will be issued during this week in a separated document (possibly by Wednesday). This is the official Working Group last call for GLUE 2.0 and we invite all of you to read the specification and to send your feedback by Friday, 12 AM CEST. By Monday 19 May, we will send the document + renderings to our area managers to be presented to the OGF Editor for promoting it to public comment. All the comments that we will receive by Friday 16 May and that can be easily incorporated, will be included. The remaining comments which may require discussion or major changes will be logged in the public comment tracker of the GLUE 2.0 specification as soon as it will be available and will be resolved during the 60 days of public comment period. When sending your feedback, pay attention to aspects related to the readability and consistency of the document. We would like to remark the importance of going to the OGF 23 with a coherent and complete document aligned with the renderings. This will enable the interested groups/projects to better evaluate the current work and create proof of concepts on real systems. We thank all of you for your contribution. Kind regards, Sergio, Balazs and Laurence PS: you can find attached the specification documents in both MS Word and PDF formats; the OGF forge portal is not reachable at the moment -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

5 14

Storage Sample in Glue 2.0
by Riccardo Zappi 09 May '08

09 May '08

Hi, I am spending some time to define an example of storage with the current Glue Schema draft. Unfortunately, I have some difficulties to represents the Data Store and the Storage Resource as you have defined into Glue Schema. Suppose a site with storage system organized with a SAN and cluster file system, like GPFS. Using the same SAN and cluster file system, I could define and mount different file systems upon the same infrastructure. For example, GPFS cluster can contain up to 256 mounted file systems. I can define some StorageShares using quota GPFS tools. In this case, the SS sizes are based on GPFS metadata. Therefore, I define StorageShare using file system feature. I imagine one StorageResource per each file system created on GPFS. In this case every StorageResource could have a size and quality properties. Some StorageShares could share the same StorageResource (i.e. file system) entity. When I try to describe how StorageResource is composed some doubts appears. I could lists all volumes composing the file system.. For example in the figure attached, you can see that 16 volumes compose the file system named ‘gpfs_storm’. In any case, heterogeneous disk devices could compose each volume... and then DataStore description appears incorrect. Are you sure that Storage Service administrator knows every details of underlying storage system? Moreover, if the admin knows, are you sure that he wants describe all these details? I think we have to improve DataStore-StorageResource concepts. Perhaps, we can go on to try to merge both concepts in only one entity with multi-valued quality properties. Cheers, Riccardo -- ------------------------------------------------------------------------------- Riccardo Zappi Istituto Nazionale di Fisica Nucleare - CNAF Viale Berti Pichat, 6/2, 40127 BOLOGNA - ITALY Phone: +39-051-609-2868 Fax: +39-051-609-2746 e-mail: riccardo.zappi(a)cnaf.infn.it -------------------------------------------------------------------------------

2 1

Comparison with CIM
by Paul Millar 09 May '08

09 May '08

Hi all, I don't know if anyone has been looking at this, but there's an emerging standard (through DMTF) in modelling "things" (computer-hardware and -software, network equipment, etc): CIM. There seems to be some cross-over here through OGF, so forgive me if this is already "well known". Anyway, for those who haven't heard of them, their schema makes for interesting reading. The current version (2.18) is available from: http://www.dmtf.org/standards/cim/cim_schema_v218 "Device" (from which a StorageDevice may be published) http://www.dmtf.org/standards/cim/cim_schema_v28/CIM_Device28-Final.pdf How to publish ACLs: http://www.dmtf.org/standards/cim/cim_schema_v218/CIM_Policy.pdf Enjoy! Paul.

8 24

TmpDir, ScratchDir and DataDir
by Sergio Andreozzi 09 May '08

09 May '08

Hi JP and Gerson, during this call http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… we agreed that the attributes TmpDir, ScratchDir and DataDir part of the Computing Resource (e.g., a batch system) should be removed: http://forge.ogf.org/sf/sfmain/do/go/artf6196 the values can be discovered by the job in the worker node environment. Do you confirm that this is ok with you? Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

3 4

Comments on GLUE Schema 2.0
by Parag Mhashilkar 06 May '08

06 May '08

Hi, Gabriele and I went through the GLUE document. We have following comments/questions - 1. Figure 1 GLUE main entities and their relationships: Based on the description for Endpoint, cardinality of Endpoint -> Service should be 1 and not 0..1. Maybe cardinality in UML diagram is still in works? 2. AccessPolicy: How can access policy be used to express Access control Base Rule? Additional info on this will be useful. Another question we had was, is it possible to express policies on FQANs and if so how? Is there an extension to this scheme and will it allow to express policies on all the elements of the certificate/proxies? For example, will it be possible to express a policy stating that "As a site I will not accept any jobs from users who have proxies valid for less than a day?" 3. Conceptual Model of the Computing Service: Based on the description of various attributes, cardinality for ComputingEndPoint->ComputingService, ComputingShare->ComputingService and ComputingResource->ComputingService should be 1..* instead of *. It might be useful in general to make sure that the description of different entities are consistent with the cardinality mentioned in the UML and vice-versa. 4. MPI jobs: >From the description of ApplicationEnvironment and ApplicationHandle it is not clear if there is a way to express Compiler Versions used to compile MPI libraries. MPI applications are quite sensitive to the compiler version and the architecture on which the libraries were compiled and need to know this in order to compile against correct set of libraries. We feel that there is no way to express this information. Also it is not clear how one can express connection between ApplicationEnvironment and ApplicationHandle. 5. Storage: We have a means to mention the storage reservation through the GLUE. Also it seems that most of the use cases are covered. 6. Appendix A: UNKNOWN data Is there a particular reason to have multiple UNDEFINED types? Can't we just have UNDEFINED instead of UNDEFINEDVALUE, UNDEFINEDPATH, UNDEFINEDUSER, etc? Are we really buying anything having multiple UNDEFINED types? 7. It will be useful to sort Appendix B alphabetically. -- Thanks & Regards ============================================================= Parag Mhashilkar Fermi National Accelerator Laboratory, MS 120 Wilson & Kirk Road, Batavia, IL - 60510. Location: Wilson Hall, WH863 Phone: +1 (630) 840-6530 Fax: +1 (630) 840-2783 Email: parag(a)fnal.gov =============================================================

3 2

Suggestion for splitting the StorageShare.
by Laurence Field 01 May '08

01 May '08

On further investigation of the Storage Schema an unmet use case has been found. Use Case: Consider two VOs who use two different paths to access the same StorageShare or alternatively one VO who can access the same StorageShare via two different paths. Where there could be an asymmetry with the ACLs for the SRM v2.2 space and the Path. The latest schema would require a StorageShare to be instantiated for each combination of path and SRM v2.2 space ACL, leading to n*m storage shares duplicating a great deal of information. The suggested solution is to split the StorageShare into the StorageShare and StorageEnvironment where there is a one to many relationship between the Environment and the Share. Both entities inherit the ACLs from the AccessPolicy StorageShare LocalID Path Tag StorageEnvironment LocalID ServingState AccessLatency RetentionPolicy ExpirationMode DefaultLifeTime MaximumLifeTime At the same time this allows the AggregationID to be removed.

7 16

Reminder: Glue 2.0 Schema Phone Conference
by Felix Nikolaus Ehm 28 Apr '08

28 Apr '08

Dear all, there will be a telephone conference for the Glue Schema 2.0 tomorrow morning at 11 AM CEST for the computing part: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeet ing20080429_11 and a storage part at 2 PM: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeet ing20080429 Please let me know if you can't make it. There is the possiblity of shifting the storage session later into the afternoon (3pm) if preferred. Cheers, Felix --- Felix Ehm IT-GD tel : +41 22 7674580 CERN, Switzerland -----------------------------------------

1 0