[glue-wg] LDAP tree

[stephen.burke at stfc.ac.uk]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
> Behalf Of Florido Paganelli said:
> First of all I would like you to notice that ALL your views are
> followed by the tree we proposed (it's not a coincidence).

No doubt, but you seem to want to specify more, and I don't think it's necessary.

> With respect to this, what do you think about the proposal by me and
> Balazs for a local level? Does it break the above?

I'm not sure what you mean - as I said I think it's OK to have some other grouping in the Nordugrid implementation if you like, but I don't think it should be included as part of the LDAP rendering specification.

> I'd love to change 'resource' into
> 'local' to make it consistent and *tell* is a local level, instead of
> having random grouping names as you seem to suggest later.

As I've said several times, for the BDII the "GLUE2GroupID=resource" usage is fixed and can't be changed, so there's no point in discussing it. On the other hand, since it isn't part of the specification you are free to do something different in Nordugrid. The group names aren't "random", they are implementation-defined.

> > However, LDAP does require that all objects whose IDs
> > are used in DNs must exist. This is one argument for not specifying
> > the DIT more than necessary.
> 
> I don't understand the above. Can you give a more detailed real-world
> example?

Consider the storage schema. Suppose that you specified that the DN of a DataStore object must be like

GLUE2ResourceID=xxx,GLUE2ManagerID=yyy,GLUE2ServiceID=zzz,...

However, an implementation could decide not to publish a StorageManager object, it carries very little information and might not be considered worthwhile. In that case it would be impossible to attach a DataStore object to the tree because there would be nothing to attach it to.

> Can you elaborate more on these IDs? GLUE2 mandates they should be
> URIs.
> Today's real world has plain strings, which I personally think is bad
> (is bad to write a OGF standard document and then hack it, I think)

I already answered that several months ago, look in the archive. Anyway it has nothing to do with this discussion.

> The pictures in the LDAP draft we reviewed with Balazs, pages 12,13,14
> http://redmine.ogf.org/dmsf_files/123?download=
> try to describe a reasonable grouping.

The question is not whether a grouping is reasonable, but whether it's necessary to have it in the specification. In my view the service and site groupings are sufficiently natural in the way the schema is structured that it's worth including them there, but other groupings are likely to vary.

> I don't think fixing the *concepts* of 'local', 'site' and 'grid'
> break anything of the above.

"Site" is implied by the schema (the first level AdminDomain to which Services relate) and "grid" as a collection of AdminDomains also seems clear. However, I don't think "local" means anything specific - in the BDII implementation (as it currently exists) the "resource" Group is purely an internal concept and doesn't correspond to anything as far as the schema is concerned, it just contains information for whatever services, or parts of services, happen to run on a particular node. (In fact they don't even have to run on that node, as long as the info provider can gather the information.) I don't think there's any more need to specify that than the names of the directories in which the info providers are placed, it's just an implementation detail that can be changed without any consequences.

> Why not leverage LDAP grouping to identify those as well? I think there
> is nothing bad in it.

The bad thing is to constrain what implementations can do for no reason.

Stephen

-- 
Scanned by iCritical.