glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@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?
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