[glue-wg] 1st Draft of the GLUE 2.0 LDAP Implementation

[Laurence Field]

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/GLUE20Errata
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE20Changes
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2LDAPDiscussion

 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 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:
> 	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
>