[glue-wg] No audio

Tue Sep 24 11:46:55 EDT 2013

Hi Laurence, all,

Some thoughts about Laurence claims that should help us sort out the issue.

On 2013-09-24 15:49, Laurence wrote:
> Hi Florido,
> 
> The question is basically flat vs nested,  similar to the XML, JSON
> discussions. As I mentioned in the previous mail, the decision at the
> time was to go with flat, i.e. not to make any assumption about the DIT.

But then I really don't understand why you put a picture of the DIT in
the rendering document, in the version before the one me and Balazs
reviewed. If you wanted to go flat you shouldn't have suggested any DIT.

The truth is that no LDAP implementation can be really flat. Here's the
reasons:

Even if we move the whole DIT to external documents, the draft will
leave these question open both for producers and consumers of information:

1) shall we mandate a tree root or not (i.e. a DN suffix)? (the already
discussed o=glue thing)  [I think this is good choice]
2) shall we suggest a use of GLUE2GroupID entries? I recall these are
NOT part of the GFD147, it's an invention that came with LDAP rendering.
[I already motivated why I like structures. no need to add here]

In spite of the above, I'd like to stress that we *CANNOT* suggest a
complete FLAT tree structure, because if so, we shoudln't use groupings.
Introducing a group introduces a dn structure and therefore a DIT.

By defining 1) we are already mandating a minimal tree structure. All
GLUE2 LDAP entries MUST be child of o=glue entry, like <glue></glue> in XML.

2) needs to be defined somewhat as it doesn't exist in the model, or
removed forever.

I followed the discussions about flat VS structure, but I think this has
little to do with that. In this case it's only about the concept of
insertion points, if these are needed or not to be explained, and how to
have a GLUE2 LDAP tree live together in a LDAP database.

To my view, whatever we do to finalize this document will diverge from
actual implementations. This is because the document NEVER reflected any
actual implementation.

> 
> I agree that this seems a little strange, as LDAP is naturally
> hierarchical, but if you have to interoperate with flat XML or JSON
> information, you would will also have an interoperability problem.
> 
> So this is more a discussion about flat vs nested. If there was an
> abstract nested model, then the LDAP DIT would naturally follow this.
> 

You're right, there is no abstract nested model.

> I have not been following the recent developments but as far as I
> understand, the predominant view is to go for a flat renderings.
> 

True; in this case we have to narrow down 'how flat' for the LDAP
technology.

Cheers,
Florido

> Laurence
> 
> 
> 
> 
> On 23/09/13 19:50, Florido Paganelli wrote:
>> Hi Laurence,
>>
>> Thanks for your contribution, as I didn't know the "story so far"
>>
>> On 2013-09-20 16:11, Laurence wrote:> Hi Florido,
>>> Just to respond to your argument in light of the comments from Andre, I
>>> think that this discussion is irrelevant.
>>>
>>> When starting the LDAP rendering, it was decided early on that the DIT
>>> would not be considered.
>>>
>>> For WLCG, it was decided that we would not make use of the DIT.
>>>
>>> The ARC middleware it seems, does make use of a DIT for the reasons that
>>> you mention.
>>>
>>> These are currently implementation choices and creating an
>>> interoperability problem (or not according to Maria).
>>>
>> I see. Differences in implementations due to fuzzy
>> specification/specification not targeted for developers lead to an
>> "interoperability problem".
>>
>> I think we wanted to solve such interoperability issues with GLUE2, but
>> it's clear I misunderstood all of it. My bad.
>>
>>> In my view (as a former co-chair of the group who started this process),
>>> the LDAP rendering should proceede without the DIT and a separate
>>> document created on the DIT if  needed for interoperability of different
>>> implementations.
>>>
>>> Defining a single DIT is only relvant for those who require this, which
>>> does not include WLCG. If there are no other implementations that
>>> require agreement on the DIT, I would suggest that you make this an ARC
>>> specific specification.
>>>
>> As I said many times, I fail to understand the above for the sake of
>> interoperability and performance, but if this is the feeling the group
>> shares, I have no other choice than to accept it.
>>
>> Regards,
>> Florido
>>
>>> Best Regards,
>>>
>>> Laurence
>>>
>>>
>>>
>>>
>>>
>>> On 19/09/13 16:26, Florido Paganelli wrote:
>>>> Hi All, JP
>>>>
>>>> On 2013-09-18 17:31, JP Navarro wrote:
>>>>> On Sep 18, 2013, at 3:02 PM, Maria Alandes Pradillo
>>>>> <Maria.Alandes.Pradillo at cern.ch> wrote:
>>>>>
>>>>>> I wonder whether we can agree on a solution that maintains the
>>>>>> current specification and maybe extends it to include Florido´s
>>>>>> changes?
>>>> I hope so, this is why we are proposing to move the DIT section to some
>>>> appendix/example of community implementation.
>>>>
>>>>> Maintaining compatibility with the current implementation and
>>>>> specification is an important goal.
>>>>>
>>>>> Even if we can do that, there is higher level debate about what
>>>>> should be in the specification, for example:
>>>>>
>>>>> There are BDII/LDAP deployment and configuration designs that are
>>>>> *necessary* for infrastructure publishers and operators, but
>>>>> *not*visible* to the users of one or multiple interoperable
>>>>> information systems.
>>>>>
>>>>> So the question is "who needs to know what the DIT is" and "who needs
>>>>> to know what the insertion points are"?
>>>>>
>>>>> If the answer is that *only* infrastructure publishers and operators,
>>>>> and NOT users, then the DIT doesn't belong in the LDAP rendering
>>>>> specification, but in a profile or community practices document.
>>>>>
>>>> I am not sure what you mean by users here. I consider users both
>>>> developers and consumers of information. I didn't know we write OGF
>>>> standards only for people who wants to consume information and not to
>>>> produce it, this suprises me a bit. I thought OGF was something  like
>>>> IEEE actually... if defines standards.
>>>>
>>>>> I believe this is the key question regarding DITs.
>>>>>
>>>> I already said on top of this email and in another email that we can
>>>> put
>>>> these "community practices" as a list of examples in the appendix. We
>>>> don't need to suggest or mandate a tree in the document, so we get
>>>> closer to a final draft.
>>>>
>>>> Anyhow, since you asked who-benefits-of-what, I just want to argument a
>>>> bit about this tree structure again.
>>>>
>>>> Coming back to my "file in a directory" example, knowing the absolute
>>>> path of a file means one can list it directly, doesn't have to run a
>>>> find for it. Knowing a *part* of the absolute path also means that one
>>>> start your find from that path and not on the entire filesystem, which
>>>> also gives you a performance benefit.
>>>>
>>>> knowing the DIT means knowing EXACTLY where an object is in the tree,
>>>> like absolute paths. Knowing part of the dn is equivalent to knowing
>>>> part on an absolute path, so it helps reducing search complexity.
>>>>
>>>> This said, usually one runs generic queries on LDAP and doesn't care
>>>> about the dn. Also, Stephen showed in previous slide that the
>>>> performance is already very much acceptable for common queries.
>>>>
>>>> However, it is clear that if a consumer (or user) *knows* the exact dn
>>>> of an object, she can retrieve that object in O(1).
>>>> If not, she has to run a search, and the search performance depends on
>>>> the complexity of the query.
>>>>
>>>> This is basically why infrastructure publishers and operators based
>>>> their implementation on minimal DIT knowledge. It just makes things
>>>> easier and faster to code. This is the same reason why we were
>>>> advocating some kind of structure in XML.
>>>>
>>>> As I said thousand times, ldap is a tree-like database, knowing the
>>>> structure of the tree is *not needed* but *if you do* then you can
>>>> query
>>>> faster than if you don't. Moreover, you will have a set of databases
>>>> structured more or less in the same way, that might even foster
>>>> harmonization, interoperability and integration between information
>>>> providers/publishers/generators, elevating GLUE2 to some kind of common
>>>> datastructure.
>>>> It's really as simple as this. But I don't want to start this topic
>>>> again. I just wanted to answer to the who-benefits-of-what question.
>>>>
>>>> Cheers,
>>>> Florido
>>> _______________________________________________
>>> glue-wg mailing list
>>> glue-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/glue-wg
>>
> 
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg

-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================