Problem with LDAP binding inherited foreign-keys
Hi all, While writing the dCache GLUE2 info-provider, I came across a problem with the current GLUE2 LDAP binding. The problem is that inherited associations are represented twice. The schema uses three kinds of LDAP class: ABSTRACT, AUXILIARY and STRUCTURAL. ABSTRACT is only used for the LDAP class for Entity (GLUE2Entity), all objects that are a directly derived from Entity are STRUCTURAL, everything else is AUXILIARY. So: LDAP classes for Service and Share (GLUE2Service and GLUE2Share respectively) are STRUCTURAL, LDAP classes for StorageService and StorageShare (GLUE2StorageService and GLUE2StorageShare) are AUXILIARY. Any published object must have at least one STRUCTURAL class and zero or more AUXILIARY classes. To publish a StorageService, the LDAP object must have GLUE2StorageService and GLUE2Service object-classes. To publish a StorageShare, the LDAP object must have GLUE2StorageShare and GLUE2Share object-classes. 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. The StorageShare object inherits this required association, only it is against a StorageService now. This association is represented as a required attribute in the GLUE2StorageShare class: the GLUE2StorageShareStorageServiceForeignKey attribute. Since a StorageShare object must be published as both GLUE2StorageShare and GLUE2Share object-classes, this object must publish the same association twice: once once as GLUE2ShareServiceForeignKey and again as GLUE2StorageShareStorageServiceForeignKey. The same problem exists for very many (perhaps all) ForeignKey attributes in AUXILIARY classes but is hidden since those foreign-key attributes are optional. I've talked to Laurence about this problem and our preferred solution is to delete GLUE2StorageShareStorageServiceForeignKey and have all a StorageShare publish their association with StorageService using a GLUE2ShareServiceForeignKey. I believe this approach will work for the other "inherited" foreign-key attributes. This solution has the disadvantage that the association between a StorageService cannot be restricted to a StorageService (and not, for example, to a ComputingService object). However, since LDAP doesn't support foreign- key constraints, such consistency may only be enforced by manual checking (gstat2, glue-validation suite, etc). So, I believe removing GLUE2StorageShareStorageServiceForeignKey doesn't loose us anything. Does this make sense? Are people in favour of this approach? Cheers, Paul.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: While writing the dCache GLUE2 info-provider, I came across a problem with the current GLUE2 LDAP binding.
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.
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 - 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.
I've talked to Laurence about this problem and our preferred solution is to delete GLUE2StorageShareStorageServiceForeignKey and have all a StorageShare publish their association with StorageService using a GLUE2ShareServiceForeignKey.
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.
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. 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. Stephen PS What happens in the XML rendering? -- Scanned by iCritical.
Hi Stephen, On Tuesday 22 February 2011 17:45:22 stephen.burke@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.
Paul Millar [mailto:paul.millar@desy.de] said:
One potential problem is that the clients don't know which attribute to use when querying.
I guess the formally correct answer would be that it depends what kind of query you're doing, but since LDAP has no real data typing or object orientation anyway it seems like an unnecessary complication.
Consequently, the info-provider should publish both, just to be sure and the client has to query both, again, just to be sure.
For the time being I think providers should publish both. As far as I know we have no clients yet (except the saga service discovery api?) so it should be possible to steer those in the right direction from the start.
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.
Perhaps, but for now I think we're constrained anyway by backward compatibility.
We could take a smooth-transition approach (like one would with a production service) or a big-bang approach.
It *is* a production service! The schema is deployed in resource, site and top-level BDIIs around the grid. The information published into it may be a beta-test, but the information system itself is in production so we do need to care about backward compatibility. Stephen -- Scanned by iCritical.
Hi, On Tue, Feb 22, 2011 at 17:45, <stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: While writing the dCache GLUE2 info-provider, I came across a problem with the current GLUE2 LDAP binding.
[skipped]
Stephen
PS What happens in the XML rendering?
The XML schema (draft) does not have this problem. It is constructed such that Associations are redefined as specified in the spec. For example ComputingShare has a ComputingEndpointID member but not a EndpointID member. Cheers, /Adrian
-- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
adrian.taga@gmail.com [mailto:adrian.taga@gmail.com] On
Behalf Of Adrian Taga said: The XML schema (draft) does not have this problem. It is constructed such that Associations are redefined as specified in the spec. For example ComputingShare has a ComputingEndpointID member but not a EndpointID member.
OK. So anyone writing translators between XML and LDAP (is anyone doing that yet?) needs to take care, but since the information is there somewhere in both representations there shouldn't be any fundamental problem. Stephen -- Scanned by iCritical.
participants (3)
-
Adrian Taga -
Paul Millar -
stephen.burke＠stfc.ac.uk