Hello all, I just commited my first draft, which does not include any foreign keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/ Do not forget to read the README file first: http://forge.ogf.org/svn/repos/glue/LDAP2/README I am willing to have any kind of feedback. :) Regards, David -- David Horat Software Engineer specialized in Grid and Web technologies IT Department – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Phone +41 22 76 77996 http://davidhorat.com/ http://cern.ch/horat http://www.linkedin.com/in/davidhorat
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I just commited my first draft, which does not include any foreign keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/
I'm just getting back to this after CHEP and Easter ... I'll reply to some of the individual mails, but I want to start with the question of how you've dealt with inheritance, because looking at your draft it seems to me that what you have is the worst of both worlds. As I understand it what you've done is not to use LDAP inheritance, i.e. the objects don't carry the parent objectclass(es), you just explicitly put the inherited attributes into the derived objectclass definitions. I can basically see two downsides to that, which go in opposite directions. One is that because the objectclasses aren't inherited you can't do a generic search for all objects of a given type - for example, doing objectclass=Service won't get the derived ComputingService and StorageService objects. On the other hand, keeping the inherited attribute names is potentially confusing. For example, in ComputingShare you have attributes called EntityName, ShareDescription and ComputingShareMappingQueue, so if people are just working with the ComputingService attributes, e.g. in the JDL, they will have to remember that some attributes are inherited and hence have different name formats. Another point maybe relates particularly to the ID, which is that if the ID of every object is called EntityID you can't tell what kind of object it refers to, and we need a globally unique ID space. I'm not immediately sure if that's a plus or a minus but it's certainly a change from current practice, where the UniqueID of each object type has its own name and where the IDs of objects of different types can be and often are identical. It seems to me that we should go one way or the other, either do it properly using inherited objectclasses or redefine and rename the attributes for each derived type. In principle it could be done differently for each case but that might well be even more confusing and I'm not sure what the argument would be for that - except perhaps for Entity where I could see a case for not explicitly inheriting it even if everything else were done with inheritance. I think my inclination is to use "real" inheritance because it will help in writing general tools, e.g. to query for the endpoints for all services - the alternative will be to always have to remember to add extra filter clauses for the special types, and to add more extra clauses if we ever introduce any more derived types. Stephen -- Scanned by iCritical.
Hi Stephen, As we received very little feedback on specific questions that were raised, a number of design decisions were made in order to provide an initial draft in a timely manner. Next week the first drafts of both the LDAP and SQL schema will be ready. It is anticipated that there will be a number of comments to these which will require further discussion in a phone conference. The main issue that has been raised during the rendering process was how to remain faithful to the document with respect to inheritance and relations. There are three options: change our expectations on the desired output, agreed on a coherent method to achieve the desired result following the current specification or to change the specification. The following wiki pages document a few points that were raised during the rendering process. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE20E... http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE20C... http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2LD... From your email, your concrete proposal suggests to use the LDAP inheritance mechanism, however, I am not sure how this fits with the abstract entities as defined in the specification. This is definitely something that we need to have some agreement with. Laurence Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I just commited my first draft, which does not include any foreign
keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/
I'm just getting back to this after CHEP and Easter ... I'll reply to some of the individual mails, but I want to start with the question of how you've dealt with inheritance, because looking at your draft it seems to me that what you have is the worst of both worlds. As I understand it what you've done is not to use LDAP inheritance, i.e. the objects don't carry the parent objectclass(es), you just explicitly put the inherited attributes into the derived objectclass definitions.
I can basically see two downsides to that, which go in opposite directions. One is that because the objectclasses aren't inherited you can't do a generic search for all objects of a given type - for example, doing objectclass=Service won't get the derived ComputingService and StorageService objects.
On the other hand, keeping the inherited attribute names is potentially confusing. For example, in ComputingShare you have attributes called EntityName, ShareDescription and ComputingShareMappingQueue, so if people are just working with the ComputingService attributes, e.g. in the JDL, they will have to remember that some attributes are inherited and hence have different name formats.
Another point maybe relates particularly to the ID, which is that if the ID of every object is called EntityID you can't tell what kind of object it refers to, and we need a globally unique ID space. I'm not immediately sure if that's a plus or a minus but it's certainly a change from current practice, where the UniqueID of each object type has its own name and where the IDs of objects of different types can be and often are identical.
It seems to me that we should go one way or the other, either do it properly using inherited objectclasses or redefine and rename the attributes for each derived type. In principle it could be done differently for each case but that might well be even more confusing and I'm not sure what the argument would be for that - except perhaps for Entity where I could see a case for not explicitly inheriting it even if everything else were done with inheritance.
I think my inclination is to use "real" inheritance because it will help in writing general tools, e.g. to query for the endpoints for all services - the alternative will be to always have to remember to add extra filter clauses for the special types, and to add more extra clauses if we ever introduce any more derived types.
Stephen
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I just commited my first draft, which does not include any foreign keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/
OK, the second general question that I haven't noticed being discussed is how we structure the DIT. Your example objects seem to just have e.g. "dn: EntityId=testExecutionEnvironment,o=grid" which isn't really viable! As I've mentioned in the past I think there may be a good case for saying that we don't require a given DIT structure, or at least allow some degree of flexibility to restructure it. Since every object now has an ID I think it's possible to say that objects should always be referenced by ID and not DN - which also relates to the ChunkKey question. However, even if we take that view we should clearly have some recommended structure (or structures). A specific question for me is whether we want to introduce some extra dummy object(s) to allow for grouping. At the moment we group by site, but everything below that is basically flat, so e.g. at CERN you have 110 GlueService objects hanging off the mds-vo-name=CERN-PROD node - and 4473 objects in total! If we group by Service object with other things below that then the structure will improve, but there may still be quite a number of Services, so I think it could be useful to introduce some kind of ServiceGroup object which would allow related services to be grouped together. You can get the same kind of thing at lower levels - an obvious example is that there could be a very large number of ComputingActivity objects, so at the very least you might want to group them all under a dedicated node and not have them hanging directly off ComputingService. We also have a particular problem with the UserDomain object, which doesn't really fit with the current site-based publishing model. Who would we expect to publish that information, and where would they put it in the tree? Stephen -- Scanned by iCritical.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) said: A specific question for me is whether we want to introduce some extra dummy object(s) to allow for grouping.
As a minimal proposal, we could define an object with objectclass=Group and one attribute GroupID which could be interposed anywhere in the tree as the implementer sees fit. That's basically what we currently do with mds-vo-name, except that we only put that near the root. Stephen -- Scanned by iCritical.
hi, quick feedback before our afternoon meeting :) Burke, S (Stephen) wrote:
OK, the second general question that I haven't noticed being discussed is how we structure the DIT. Your example objects seem to just have e.g. "dn: EntityId=testExecutionEnvironment,o=grid" which isn't really viable! As I've mentioned in the past I think there may be a good case for saying that we don't require a given DIT structure, or at least allow some degree of flexibility to restructure it. Since every object now has an ID I think it's possible to say that objects should always be referenced by ID and not DN - which also relates to the ChunkKey question. However, even if we take that view we should clearly have some recommended structure (or structures).
From the nordugrid experience we find the DIT very important. According to our view the LDAP rendering must come with a recommendation for DIT. This was one of our main issues with glue-1.3.
A specific question for me is whether we want to introduce some extra dummy object(s) to allow for grouping.
grouping is also important. we have the same in our ldap tree, we created a dummy object to group e.g. job entries under queues. btw, there is a similar grouping introduced in the xml rendering. bye, Balazs
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Balazs Konya said: From the nordugrid experience we find the DIT very important. According to our view the LDAP rendering must come with a recommendation for DIT.
A recommendation would imply that people are allowed to do something different ... also it's possible that we make some things mandatory and others not, e.g. we could prescribe how the tree looks at the level below Service, but not at higher levels. Or we could say that all the subsidiary classes should be somewhere below Service, but not say exactly where. I think anyway we will end up with something a bit strange, because in the schema the Resource and Share classes are not directly children of Service, but are related to both Endpoint and Manager, which obviously doesn't fit a tree structure. Also we have to cope with the possibility that some objects are not published at all - if your tree goes Service -> Manager -> Resource and the Manager is not published, what happens? The other side is whether we say that clients should always construct queries using IDs. To me that seems attractive; I don't think there is much performance penalty if the IDs are indexed, and it would even mean that you could use multiple technologies, e.g. query some things from LDAP and others from XML. Stephen -- Scanned by iCritical.
participants (4)
-
Balazs Konya -
Burke, S (Stephen) -
David Horat -
Laurence Field