Hi Stephen, Thanks for the comments and info. My comments are... On Thursday 08 May 2008 16:37:57 Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: True, but OGF-GLUE-WG does provide the GLUE/LDAP binding, which I feel currently is lacking some documentation.
GLUE is only an OGF WG for the Glue 2.0 spec, so while it will produce an LDAP binding for 2.0 it doesn't have any direct responsibility for 1.3. Indeed for 1.2 and 1.3 there was no GLUE project as such, the original GLUE wound up several years back.
OK, fair enough, but I'd mark this one down as "inherited debt": someone should be "maintaining" (in the ISO meaning of the word) the GLUE v1.3 standard since it's in active use. Perhaps this should be the OGF GLUE WG? Besides, many of the people in GLUE WG are among the authors of the GLUE v1.3 specification and adding a wiki page isn't such an onerous task.
So, for these reasons, one cannot (reasonably) claim that the schema is the single authoritative source as schemata can only validate a document, which is a lesser requirement than correctness.
Being picky, the schema is in fact the only authoritative source
Yes, with the schema one can make an authoritative statement, but only in answer to one question: is a document is valid? Ensuring documents are valid is very useful, but it really isn't sufficient: we want documents (i.e., LDIF information) that are going to be *useful* to people. Not all valid documents are useful. Here's an explicit example. (I believe) one can publish the following object: dn: GlueSEAccessProtocolLocalID=gridftp@example.org,GlueSEUniqueID=example.org,mds-vo-name=resource,o=grid objectClass: GlueSETop objectClass: GlueSEAccessProtocol objectClass: GlueKey GlueSEAccessProtocolLocalID: gridftp@example.org GlueSEAccessProtocolType: gridftp GlueSEAccessProtocolEndpoint: gridftp://milliways.example.org:2811 GlueSEAccessProtocolCapability: file transfer GlueSEAccessProtocolVersion: 1.0 GlueSEAccessProtocolMaxStreams: 20 GlueSEAccessProtocolPort: 2811 GlueSEAccessProtocolSupportedSecurity: GSI GlueChunkKey: GlueSEUniqueID=bogusValue (I believe) this will pass the LDAP Schema checks (the attribute value is a valid IA5String) so the object is valid; however, it's certainly not "correct" as the GlueChunkKey points the end-user to a GlueSEUniqueID that doesn't match the corresponding RDN within the DN. Another example would be the same object, but published without the GlueKey objectClass and without any GlueChunkKey attribute. This, too, would be valid LDIF (I believe) and also not "correct": Glue-v1.3 specifies a link from AccessProtocol to StorageElement (see Glue-v1.3, page 14). This link would be missing on LDAPv2 implementations (with LDAPv3 it is available through the :dn: extension to the query language, but I believe we're leaving that out of the current discussion). This is the difference between a document being valid and (what I mean by) "correct": valid documents pass the schema, correct documents mean no one can (reasonably) complain the information is in some way wrong.
while it might be nice to have some additional definitive document we don't actually have one!
Exactly: someone should create this additional definitive document; a wiki page would be sufficient. (IMHO the absence, so-far, of documentation is not a great argument for its continued absence!)
Most things are, but the GlueChunkKey (as one example) isn't.
That's because it's only in the LDAP implementation
Exactly! GLUE/LDAP has some information that should be document that are both: i) specific to the GLUE/LDAP binding, ii) for technical reasons, are not covered by the LDAP Schema. The format of GlueChunkKey is one, there may be other things.
but anyway, as I say I don't think [GlueChunkKey] should be obsoleted, and it certainly isn't for 1.3.
Yup, fair enough. Personally, I don't care one way or the other. If it's needed by people querying the info-system, we should provide it. However, by the same token, if it *is* needed, there should be a document describing how to generate the values, for which objectClasses it is needed, etc...
[GlueService -URI and -URL attributes being removed] The GlueService things are LCG-specific because those attributes were never officially part of GLUE at all
Err... so, out of idle curiosity, if these attributes are LCG extensions, why did the attributes being with "Glue"? Would something else (for example, "LCG") not have been a better prefix? There's a more general issue here: should GLUE reserve some part of the name-space? (This could be more of a "Gentleman's agreement" than a rigid partitioning.) Apart from avoiding confusion, Glue reserving some part of the name-space might help prevent future problems; for example, if a version 1.4 of GLUE was introduced that defines a new attribute "GlueServiceURI", but with different semantics to LCG's usage (e.g., LCG allowed GlueServiceURI attribute values that are not a URI, but GLUE requires all values to be a URI), this would cause problems.
(LCG had its own Service object at one time).
Fair enough. I guess EGEE, LCG or any group should feel free to publish additional information, provided it doesn't conflict with Glue information. [...]
[As an aside: does EGEE/WLCG document that GlueService -URI / -URL are no longer required? Is there anyway of being notification when these requirements change?]
Not really, because it's a question of fixing individual bugs - those attributes should never have been used in the first place, but they were published because there was code that did in fact use them.
The correctness or otherwise of publishing some attributes aside, if there are changes in what data the info-providers should provide then the people writing those info-providers *need* to know. When there are changes, there must be timely dissemination of these changes within the developer community.
[changes to GLUE schema] Unfortunately we quite often hit problems like that, where we can't in practice publish according to the schema because there is broken code making invalid assumptions and it takes time to get things fixed.
Hmm... I'm not sure if, with "code making invalid assumptions", you're referring to the info-providers or the underlying systems. I first read this as referring to the underlying services and a little warning bell (marked "horse before cart") just went off in my head. If so, to me this sounds more like the schema is making invalid assumptions about the services so the schema is broken; requiring the underlying services to change so the correct information can be publish seems bizarre. Of course, if you're referring to the info-providers, then that's fair enough (although it does hint that "correct" is insufficiently defined).
[publishing GLUE (v1.3 in particular) as a EGEE issue]
Well, yes and no - SRM is a general standard and now also an OGF WG so the general question of how SRM v2 should be reflected in GLUE goes beyond WLCG, it just happens to be the case that WLCG is currently the main user.
This sounds like a good idea to me. Does this mean that (someone within) GLUE is going to provide documentation that describes how to map SRM v2.2 concepts to GLUE v1.3? A wiki page would be good.
Agreed. Which forum within EGEE (or WLCG) discusses its adoption of GLUE?
It was the GSSD group, but I'm not sure if that still exists (Maarten?).
Aye, but I believe GSSD is specifically storage and not specifically GLUE; so, although the should (IMHO) have a strong influence on EGEE's usage of GLUE for storage, they're not the forum that decides how EGEE should use GLUE. Cheers, Paul. (who often gets confused due to the plethora of groups, boards and panels our community seems to develop!)