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

[Burke, S (Stephen)]

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.

> 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 - while
it might be nice to have some additional definitive document we don't
actually have one!

> Most things are, but the GlueChunkKey (as one example) isn't. 

That's because it's only in the LDAP implementation - but anyway, as I
say I don't think it should be obsoleted, and it certainly isn't for
1.3.

> > specifically, the old GlueService URI and URL attributes 
> have been removed
> > from my service publisher, which is just in the process of 
> being released,
> > and the CE renaming of CPUs to Slots is true but we still 
> publish CPUs as
> > well. 
> 
> Yes, but these are EGEE/WLCG issues, right?

The GlueService things are LCG-specific because those attributes were
never officially part of GLUE at all (LCG had its own Service object at
one time). CPUs -> Slots is a general schema issue.

> [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.
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.

> > As for the proposal, it suggests that all space tokens of a 
> given type
> > should be merged into a single SA, but personally I still 
> think that we
> > should publish one SA per token - this is e.g. how Jens' 
> castor provider
> > works and I find it extremely useful to keep track of free and used
> > space.
> > Again, I guess this is a EGEE/WLCG issue; not that it isn't 
> interesting, but 
> I'm trying to limit myself to just OGF-GLUE-WG issues.

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.

> 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?).

Stephen