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

Burke, S (Stephen) S.Burke at rl.ac.uk
Wed May 7 12:09:27 CDT 2008


glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Paul Millar said:
> I've started a dCache wiki page[1] that 
> holds various 
> nuggets of information, but none of them seem complete or 
> authoritative.

Bear in mind that GLUE and the gip live in different domains, so nothing
is authoritative for both (and the LDAP schema is different again). The
GSSD wiki is at yet another level, it's only for LCG and is only a
recommendation - and personally I think is wrong in at least one respect
(see below). For Glue 1.3, which is presumably what you're currently
implementing, OGF is not directly relevant although the web site does
have various useful documents.

> Second, I could also find no authoritative source of 
> information on Glue/LDAP binding for v1.3.

Fundamentally there is only one authoritative source, namely the actual
LDAP schema in cvs! (as Maarten already pointed out.)

  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

Persoanally I think that whole page should be deprecated ... most of it
is not relevant to the deployed schema, and as I argued a while back the
ChunkKey at least is important and we should keep it in Glue 2. Most of
the other things are in the schema document anyway - 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. 

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

The mds-vo-name part varies depending on where you query: = resource at
the lowest level (and in the info provider), = <site-name> from a site
BDII, and = local from a top-level BDII. BDIIs all have their root DN at
o=grid so you can always query from there, but the mds-vo-name is still
used as a second-level filter even though MDS itself is now completely
gone.

  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. However, we should discuss this more offline as this is not an
OGF/Glue 2 issue.

> 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,

Well, it's LDIF conforming to the 1.3 schema, basically what you get
from ldapsearch. As above, info providers need to publish their objects
with DNs ending "mds-vo-name=resource,o=grid". It may also be worth
pointing out that you can publish in two different ways: info providers
publish entire objects, whereas gip plugins just publish the changes
relative to a static file created by YAIM. Laurence will no doubt say
more, but this is the wiki page:

https://twiki.cern.ch/twiki//bin/view/EGEE/InformationSystem

Stephen


More information about the glue-wg mailing list