[glue-wg] LDAP rendering document: new version as an outcome of Lund review

[Florido Paganelli]

On 06/14/2012 05:33 PM, stephen.burke at stfc.ac.uk wrote:
> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
>> Behalf Of Balazs Konya said: I've just uploaded a new version of
>> the "GLUE v. 2.0 – Reference Realization to LDAP Schema" ldap
>> rendering draft to the glue2 gridforge area. The uploaded new
>> version contains comments and tracks all the changes we made in the
>> document.
>
> I haven't yet read the new document in detail, but as the author of
> the previous version I have a few general comments. Firstly, I don't
> think it's accurate to describe this as a revision of the existing
> document; it seems to be substantially a new document describing a
> significantly different rendering. I would personally prefer to
> separate textual and minor technical comments on the existing text
> from substantive changes to the structure.
>
> Secondly, the history of this is that the LDAP rendering was
> discussed in this mailing list and in open meetings in mid-2009, the
> resulting LDAP schema was then implemented and we've spent nearly
> three years deploying it in production in EGEE and EGI. Given the
> practicalities of deployment I think it's essentially impossible to
> make any backward-incompatible changes at this stage, and even
> backward-compatible changes would probably take several years to
> propagate across the whole Grid, so regardless of how the document
> changes the major existing implementation is basically fixed.
>

with all the respect, you should just read the document, and you'll 
notice that the spirit is really to sync it with the current 
implementations at the best, correcting deviations that might make the 
implementation not capable of using the unique features of the 
underlying technology, or improving (mostly human) readability.

Is completely absurd for me to mimic a relational database behaviour in 
a years-old hierarchical database system such as LDAP, it's just an 
overkill.

I believe there is no real backward incompatible change that cannot be 
fixed in a simple minor update; the logic is there, we're speaking about 
renaming of groups, which is in line with the previous version of the 
documents. I clearly remember an exchange of email where you said the 
structure of the tree is not important. Did you change your mind?
I think it _is_ important in a hierarchical database...

> The previous document was intended to correspond to what was actually
> implemented but may not do so in every respect - for example it seems
> that we failed to change string types from IA5String to
> DirectoryString in the deployed schema. I think that's unfortunate
> but we will in practice have to live with it as a restriction (as we
> did for GLUE 1) - in that case we could change the schema since it
> would be backward-compatible, but it would be a long time before
> non-ASCII characters could be used reliably.

But why is that? I didn't understand the problem there, I was not part 
of the process at that time, sorry

>
> It is of course possible to have variant implementations, and to some
> extent variants can be covered by a single document, e.g. it was
> explicitly intended to allow the DIT to be flexible. However, at some
> point if it's really desired to have renderings which differ in major
> ways I think it would be better to have separate documents.

We kept the DIT flexible but if one wants to achieve performance then he 
must enforce the benefits of the underlying technology, IMHO. That's the 
idea behind suggesting a pre-defined tree structure.

But check it, is no big difference with the existing implementations!

I'll try to explain better during the meeting.

Cheers
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project