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. 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. 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. 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. 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. Stephen -- Scanned by iCritical.
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@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
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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.
participants (2)
-
Florido Paganelli -
stephen.burke＠stfc.ac.uk