September 2012 - glue-wg

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

Summary of changes in LDAP GLUE2 rendering as requested in last meeting
by Florido Paganelli 20 Sep '12

20 Sep '12

Dear all, Here is the requested summary for the latest changes in the LDAP Realization draft. (see meeting notes http://redmine.ogf.org/projects/glue-wg/wiki/29_August_2012) We really would like to progress with this document and reach an agreement for the document ready to be submitted to the ogf procedure in one month. The LDAP document was tracked for changes to the purpose of making it easy to check differences between previous versions. Version 6.0: http://redmine.ogf.org/dmsf_files/123?download=264 The document also contains open questions that we would like the group to discuss. These are recorded as comments in the draft. We strongly recommend to go through all the changes and give feedback if some of the changes is questionable. Below we list the major structural modifications: C1) Rewrite of Section 3.7: Directory Information Tree The old document contained a proposed DIT that was incomplete and not followed by any of the actual implementations. We almost completely rewrote the section on DIT, introduced three-level information structuring and provided three detailed pictures that correspond to actual implementation apart from minor proposed changes. This is the section that actually contains most of the changes and should be read. C2) Section 3.5 Datatypes We corrected the datatypes to match the current LDAP schema used by EMI. C3) All over the document: followed the RFC4512 terminology, e.g. renamed "ldap objects" to "ldap entries". The following open questions arised during the review, and we would like the group to discuss them: Q1) Section 3.4, Object Class types and Inheritance Choice of structural/auxiliary should be revised. Seems too restrictive to allow only the first child of the Entity to be structural. For example: ComputingService is not structural. Q2) Section 3.4, Object Class types and Inheritance The strange and complex choice on the LDAP attribute names selected to form DNs is not motivated and explained. We would like to discuss a major simplification that makes implementation straightforward. For example, What is the benefit not to have GLUE2Endpoint instead of GLUE2ComputingEndpointID or GLUE2ServiceID instead of GLUE2StorageServiceID, while all the less important entities such as Benchmark have their own GLUE2BenchmarkID? Q3) Section 3.8, OID assignments The used OID allocation mechanism is not extensible when it comes to adding attributes to entry. Furthermore, the choice is strange, it is not applied consistently and its benefits are unclear. Explaining this in a email is not easy, one really needs to read the section and come back for discussion. Regards, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

5 9

LDAP tree
by stephen.burke＠stfc.ac.uk 04 Sep '12

04 Sep '12

Hi, I'd like to summarise my views on what aspects of the LDAP DIT should be specified: o The base DN is o=glue. o Extension objects must be immediately below the object they extend (below meaning further from the base DN) because they are logically part of that object. o Service grouping: if there is a Service object, any component objects that relate to it must be somewhere below it in the tree, and no other objects must be there. That means for example that you can remove a Service by deleting the Service object and its subtree. o Site grouping: Services relate to exactly one AdminDomain object which represents the concept of a Grid site (possibly distributed). Similarly to the Service grouping, the tree below an AdminDomain should normally contain all the objects related to it and not objects that relate to other AdminDomains. However, it may be that that can't be an absolute requirement because distributed sites might need a more complex publishing scheme. o Object existence: in general objects are not required to exist in a given server even if references to them exist. For example it may be useful to have a specialised server which only contains some types of object, and an implementation may choose not to publish some types of object at all. However, LDAP does require that all objects whose IDs are used in DNs must exist. This is one argument for not specifying the DIT more than necessary. o Site information: an LDAP server which publishes information for a single site should use a base DN of DomainID=<site-name>,o=glue. That follows naturally from the site grouping principle. o Grid information: an LDAP server which collects information from a range of sites across the Grid should use a base DN of GLUE2GroupID=grid,o=glue. That allows, for example, a single server to provide both site-level and Grid-level information. o Other information: any other information grouping should be published under a base DN of GLUE2GroupID=<group-name>,o=glue, where the group-name is defined by the implementation. o Anything else is free for an implementation to choose. In particular the number of nodes in the tree between any two objects is not defined (other than for Extensions), because it may be convenient to insert grouping objects. I would also like to explain my view on what the LDAP rendering document should and should not specify. Essentially I see it as specifying the LDAP schema and some aspects of the DIT construction as described above. I do not think it should specify anything about a particular implementation technology, notably the BDII, because we want to be free to evolve that technology without breaking compatibility with external clients, by which I mean any software which queries LDAP servers for GLUE 2 information. It also leaves it open to other Grid projects, e.g. OSG or Nordugrid, to develop a different technology which can be interoperable as long as they use the same schema. Stephen -- Scanned by iCritical.

2 2