[glue-wg] 1st Draft of the GLUE 2.0 LDAP Implementation
Laurence.Field at cern.ch
Thu Apr 16 07:16:48 CDT 2009
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.
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.
Burke, S (Stephen) wrote:
> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at 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:
> 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
> 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.
More information about the glue-wg