[glue-wg] Problem with LDAP binding inherited foreign-keys

[Paul Millar]

Hi Stephen,

On Tuesday 22 February 2011 17:45:22 stephen.burke at stfc.ac.uk wrote:
> Yes, we saw the same thing with the computing service. I think I'd describe
> it as a feature rather than a problem - it's a logical outcome of the way
> we defined the LDAP binding and it does no particular harm other than
> increasing the data volume a bit, but it is a little odd.

One potential problem is that the clients don't know which attribute to use 
when querying.  Consequently, the info-provider should publish both, just to 
be sure and the client has to query both, again, just to be sure.

I'm not sure what benefit this bring and it certainly breaks the normalisation 
rules of data storage (every piece of information has a single place where an 
authoritative copy is found).

> > In GLUE v2.0, the Share object has a required (i.e., multiplicity of
> > '1')
> > association with a Service.  This is represented in the LDAP Schema as
> > a
> > required attribute in the GLUE2Share class: the
> > GLUE2ShareServiceForeignKey attribute.
> 
> Except that it actually seems to be defined as optional

You're right.

Sorry, I actually meant GLUE2StorageEndpointStorageServiceForeignKey and 
GLUE2EndpointService, which both 'MUST' be published.

The same problem exists for other inherited foreign-keys in AUXILIARY LDAP 
classes.

> - I think that was an attempt to deal with this problem, but to my mind
> it's the wrong solution, I think the basic relations should be mandatory.

Agreed.  This is the wrong solution to the problem: the basic associations, if 
mandatory, should be just as mandatory as the inherited ones.


> If we only publish one ForeignKey attribute I agree that it should be that
> one, e.g. I think you should be able to navigate from any kind of Share to
> any kind of Service by using the same attribute.

exactly.

> > Does this make sense?  Are people in favour of this approach?
> 
> Broadly yes - although I would suggest making the specialised attributes
> (GLUE2StorageShareStorageServiceForeignKey etc) optional rather than
> deleting them completely, in case we subsequently find a reason to use
> them.

For me, I feel the risk of people publishing them, or querying against them, 
is greater than the risk that we remove them and subsequently discover a use 
for them.

But, if others want to keep them, I'm OK, provided it says somewhere, clearly, 
that they are not to be used.

>   Also we have a transitional problem - right now publishers have to
> publish those keys because it's a mandatory attribute, so if we delete the
> attribute we have to upgrade the schema and all publishers ~
> simultaneously which is next to impossible even for something which is
> still only being tested. If we change it to being optional then everything
> will be happy with publishers that include them, and they can be retired
> later.

We could take a smooth-transition approach (like one would with a production 
service) or a big-bang approach.

Since the info-providers haven't really been released yet, I would go for the 
big-bang.  I think this would be the quickest way to fix the problem.

But I guess, at least within EMI, the PTB should make a decision on this.

Cheers,

Paul.