[glue-wg] v1.3 documentation, please!

[Paul Millar]

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 at ogf.org
>
> > [mailto:glue-wg-bounces at 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 at example.org,GlueSEUniqueID=example.org,mds-vo-name=resource,o=grid
objectClass: GlueSETop
objectClass: GlueSEAccessProtocol
objectClass: GlueKey
GlueSEAccessProtocolLocalID: gridftp at 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!)