[glue-wg] Finalizing the LDAP implementation of GLUE 2.0

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
David Horat said:
> I am trying finalizing the initial draft of the LDAP implementation
and have a few questions that need to be resolved before I can finish.

These were mostly addressed in other mails, but for completeness:

> So in the Entity class, should Extension.LocalId be specified instead
of Extension.Key? 

Yes.

> The relations  in the association end list are always specified with
the attribute they have to link with. (E.g. Service.ID). There are
several reasons why this may not be a good idea.

In GLUE the key for every object (except Extension) is *defined* to be
the EntityID, so this is correct.

> From the theoretical definition of inheritance, just by pointing to a
class we cannot be sure to have access to its subclasses, only to its
superclasses.

That isn't directly relevant in that LDAP queries are not object
oriented and you do have access to everything. I.e. you can happily do a
query like

ldapsearch <blah> objectclass=Entity EntityID EndpointURL
ComputingEndpointRunningJobs

although I doubt that that particular query is very useful!

  Also many attributes are optional so code anyway can't assume their
presence, whether they come from the main class or a derived class.
However, this is related to why I think it would be a good idea to use
real objectclass inheritance: it means you can do a query like

ldapsearch <blah> objectclass=Endpoint EndpointURL

to get the endpoint for every service, as opposed to

ldapsearch <blah>
(&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor
ageEndpoint)) EndpointURL

or even

ldapsearch <blah>
(&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor
ageEndpoint)) EndpointURL ComputingEndpointURL StorageEndpointURL

(and in the last case, consider the possible mess if I want to query
with restrictions on HealthState, ServingState, QualityLevel, ...).

If we do use inheritance it will also affect the way the keys work, i.e.
if Endpoint has a key pointing to Service then it will automatically be
inherited by ComputingEndpoint and StorageEndpoint. And I believe that
Sergio said that we should not have "mixed" relations, i.e. that a
ComputingService will only have relations to ComputingEndpoints and not
to Endpoints, so there is then no need for any other kind of key.

> In addition to the questions above, I have three proposals on how to
implement the relationships and would appreciate some feedback on each
of them and which one is prefered. 

As above, it depends on the decision about inheritance, attribute naming
and uniqueness of IDs.

> Also should we use 'FK' or 'ForeignKey'?.

Out of those two it should be ForeignKey. However, an alternative would
be to call them e.g.

LocationServiceID

which is more explicit.

Stephen
-- 
Scanned by iCritical.