[glue-wg] LDAP tree

[Florido Paganelli]

Hi Stephen,

Very nice summary!

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

Further comments inline

On 2012-09-03 22:00, stephen.burke at stfc.ac.uk wrote:
> Hi,
>
> I'd like to summarise my views on what aspects of the LDAP DIT should
> be specified:
>
> o The base DN is o=glue.
>
> o Extension objects must be immediately below the object they extend
> (below meaning further from the base DN) because they are logically
> part of that object.
>
> o Service grouping: if there is a Service object, any component
> objects that relate to it must be somewhere below it in the tree, and
> no other objects must be there. That means for example that you can
> remove a Service by deleting the Service object and its subtree.
>
> o Site grouping: Services relate to exactly one AdminDomain object
> which represents the concept of a Grid site (possibly distributed).
> Similarly to the Service grouping, the tree below an AdminDomain
> should normally contain all the objects related to it and not objects
> that relate to other AdminDomains. However, it may be that that can't
> be an absolute requirement because distributed sites might need a
> more complex publishing scheme.
>

With respect to this, what do you think about the proposal by me and 
Balazs for a local level? Does it break the above? Recall that a local 
level is not a site itself, but just says "I belong to a site", might or 
might not be distributed

For example, the LDAP draft (even the previous one) allowed for such a 
configuration:

o=glue
   |--GLUE2AdminDomain=siteName
   |
   |--GLUE2GroupID=resource
          |--GLUE2Service=...
               <All services here>

that we currently have in ARC CEs. 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. I added a 
comment about that below.

> o Object existence: in general objects are not required to exist in a
> given server even if references to them exist. For example it may be
> useful to have a specialised server which only contains some types of
> object, and an implementation may choose not to publish some types of
> object at all. 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?

> o Site information: an LDAP server which publishes information for a
> single site should use a base DN of DomainID=<site-name>,o=glue. That
> follows naturally from the site grouping principle.
>

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)

> o Grid information: an LDAP server which collects information from a
> range of sites across the Grid should use a base DN of
> GLUE2GroupID=grid,o=glue. That allows, for example, a single server
> to provide both site-level and Grid-level information.
>
> o Other information: any other information grouping should be
> published under a base DN of GLUE2GroupID=<group-name>,o=glue, where
> the group-name is defined by the implementation.
>

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.

I like the idea to give freedom to create new groups, but I'd like to 
suggest some unique names for special groups in order to identify local, 
site ( as aggregation of local levels) and grid (as aggregation of 
sites) concepts.

I have better pictures I should integrate. They will be integrated in 
the document once me and Balazs write down the summary you asked.


> o Anything else is free for an implementation to choose. In
> particular the number of nodes in the tree between any two objects is
> not defined (other than for Extensions), because it may be convenient
> to insert grouping objects.
>
> I would also like to explain my view on what the LDAP rendering
> document should and should not specify. Essentially I see it as
> specifying the LDAP schema and some aspects of the DIT construction
> as described above. I do not think it should specify anything about a
> particular implementation technology, notably the BDII, because we
> want to be free to evolve that technology without breaking
> compatibility with external clients, by which I mean any software
> which queries LDAP servers for GLUE 2 information. It also leaves it
> open to other Grid projects, e.g. OSG or Nordugrid, to develop a
> different technology which can be interoperable as long as they use
> the same schema.
>

I don't think fixing the *concepts* of 'local', 'site' and 'grid' breaks 
anything of the above. At least the two levels local and grid 
(aggregation), they will for sure make sense always. Don't you think so? 
Why not leverage LDAP grouping to identify those as well? I think there 
is nothing bad in it.

Cheers,
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project