Summary of changes in LDAP GLUE2 rendering as requested in last meeting
Dear all, Here is the requested summary for the latest changes in the LDAP Realization draft. (see meeting notes http://redmine.ogf.org/projects/glue-wg/wiki/29_August_2012) We really would like to progress with this document and reach an agreement for the document ready to be submitted to the ogf procedure in one month. The LDAP document was tracked for changes to the purpose of making it easy to check differences between previous versions. Version 6.0: http://redmine.ogf.org/dmsf_files/123?download=264 The document also contains open questions that we would like the group to discuss. These are recorded as comments in the draft. We strongly recommend to go through all the changes and give feedback if some of the changes is questionable. Below we list the major structural modifications: C1) Rewrite of Section 3.7: Directory Information Tree The old document contained a proposed DIT that was incomplete and not followed by any of the actual implementations. We almost completely rewrote the section on DIT, introduced three-level information structuring and provided three detailed pictures that correspond to actual implementation apart from minor proposed changes. This is the section that actually contains most of the changes and should be read. C2) Section 3.5 Datatypes We corrected the datatypes to match the current LDAP schema used by EMI. C3) All over the document: followed the RFC4512 terminology, e.g. renamed "ldap objects" to "ldap entries". The following open questions arised during the review, and we would like the group to discuss them: Q1) Section 3.4, Object Class types and Inheritance Choice of structural/auxiliary should be revised. Seems too restrictive to allow only the first child of the Entity to be structural. For example: ComputingService is not structural. Q2) Section 3.4, Object Class types and Inheritance The strange and complex choice on the LDAP attribute names selected to form DNs is not motivated and explained. We would like to discuss a major simplification that makes implementation straightforward. For example, What is the benefit not to have GLUE2Endpoint instead of GLUE2ComputingEndpointID or GLUE2ServiceID instead of GLUE2StorageServiceID, while all the less important entities such as Benchmark have their own GLUE2BenchmarkID? Q3) Section 3.8, OID assignments The used OID allocation mechanism is not extensible when it comes to adding attributes to entry. Furthermore, the choice is strange, it is not applied consistently and its benefits are unclear. Explaining this in a email is not easy, one really needs to read the section and come back for discussion. Regards, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
We really would like to progress with this document and reach an agreement for the document ready to be submitted to the ogf procedure in one month.
It seems clear that Florido and I will not agree on most of these points, so I'd like to ask the rest of the group how they would like to proceed in reaching a conclusion on this. Stephen
Dear Stephen, Glue group, On 2012-09-17 23:15, stephen.burke@stfc.ac.uk wrote:
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
We really would like to progress with this document and reach an agreement for the document ready to be submitted to the ogf procedure in one month.
It seems clear that Florido and I will not agree on most of these points, so I'd like to ask the rest of the group how they would like to proceed in reaching a conclusion on this.
Would it be possible that you go through the detailed feedback, the tracked changed document and write down what you actually disagree with? Then, there'll be (a series?) of phone meetings or if necessary even a face to face meeting so that some decision is to taken. The decision making process in OGF is not very well defined, therefore if possible a consensus is always preferred. Balazs Konya as OGF Glue WG co-chair this time -- Balázs Kónya Technical Director European Middleware Initiative www.eu-emi.eu NorduGrid Collaboration www.nordugrid.org Lund University balazs.konya@hep.lu.se Department of Physics phone: +46 46 222 8049 BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015
Hi Balasz, On Tue, Sep 18, 2012 at 10:41 AM, Balazs Konya <balazs.konya@hep.lu.se> wrote:
Dear Stephen, Glue group,
The decision making process in OGF is not very well defined, therefore if possible a consensus is always preferred.
See GFD.3 (http://ogf.org/documents/GFD.3.pdf), section 3.5, paragraph 1: "The working group or research group chair is responsible for ensuring that the group makes progress toward the objectives outlined in the group charter and that the group process is fair, open, and marked by consensus. An excellent overview of the responsibilities and role of a working group chair can be found in [1], and a similar overview of the responsibilities and role of a research group chair can be found in [5]." [1] is RFC-2418 (http://www.ietf.org/rfc/rfc2418.txt) (OGF is explicitly modeled after IETF), where section 3 describes the WG operation processes in some detail, including how to define consensus. In particular 3.3 states: "Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. [...] Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached." So, you as a chair should provide the consensus process which fits your group best, and you as chair are responsible for defining when consensus has been reached. Several OGF groups have stalled in the past because chairs did not dare to make that call *sigh* Sorry for the heavyweight reply to a likely off-handed remark, but I hear that point very often, and we would really get rid of the image that OGF processes are ill defined. It is simply that ADs/chairs/members did not read the documents they should read (GFD.2, GFD.3, GFD.152), and/or did not communicate the relevant parts to the groups. Best, Andre :-)
Balazs Konya as OGF Glue WG co-chair this time
-- Balázs Kónya
Technical Director
European Middleware Initiative www.eu-emi.eu NorduGrid Collaboration www.nordugrid.org
Lund University balazs.konya@hep.lu.se Department of Physics phone: +46 46 222 8049 BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Nothing is really difficult...
Dear Balazs, The decision making process in OGF is not very well defined, therefore if possible a consensus is always preferred. Well, I partly disagree. As a group we have recently made an unprecedented :) decision on the style of xml schema - which is a good progress. For the ldap, I insist that we should follow the same procedure either a face-to-face/telephone meeting(s) within the boundaries of OGF-GLUE WG to reach the consensus, asap. HTH, Shiraz Balazs Konya as OGF Glue WG co-chair this time -- Balázs Kónya Technical Director European Middleware Initiative www.eu-emi.eu<http://www.eu-emi.eu> NorduGrid Collaboration www.nordugrid.org<http://www.nordugrid.org> Lund University balazs.konya@hep.lu.se<mailto:balazs.konya@hep.lu.se> Department of Physics phone: +46 46 222 8049<tel:%2B46%2046%20222%208049> BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015<tel:%2B46%2046%20222%204015> _______________________________________________ glue-wg mailing list glue-wg@ogf.org<mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
C1) Rewrite of Section 3.7: Directory Information Tree
I've described my position on this several times, basically I don't agree with the proposed changes. I'm not going to change my view and it doesn't seem that Florido is either, so someone else will have to arbitrate. One point I would make is that the XML discussion seems to have gone in the opposite direction - at the start Florido wanted the LDAP tree to match the XML hierarchy, but now the XML is almost completely flat which is a more extreme position than I propose for LDAP, where I do think that grouping by Service and AdminDomain is useful - although not essential. If we wanted to remove all references to the tree from the document and leave it to be completely implementation-defined I would probably prefer that to defining the tree more rigidly.
C2) Section 3.5 Datatypes We corrected the datatypes to match the current LDAP schema used by EMI.
As we somewhat discussed a while ago, this is a real problem and not just a textual change. We need to discuss it as a separate item - it's not only relevant to LDAP.
C3) All over the document: followed the RFC4512 terminology, e.g. renamed "ldap objects" to "ldap entries".
I would also reject that - it's true that the technically correct term is "entry" but I think it just makes the document less comprehensible, I would be surprised if many people would understand what "entry" means.
The following open questions arised during the review, and we would like the group to discuss them:
I think discussing these is pointless, they were decided, implemented and deployed long ago, so it's much too late to reopen them. If Nordugrid want to develop a completely new implementation they should start a new document. Stephen
Dear Stephen, I'd like to make my usual comment that somehow always gets forgotten :( On 9/19/2012 11:16 AM, stephen.burke@stfc.ac.uk wrote:
The following open questions arised during the review, and we would like the group to discuss them:
I think discussing these is pointless, they were decided, implemented and deployed long ago, so it's much too late to reopen them.
as far as i know this is the first real review of the old draft. the original version was prepared in a big hurry by a single technology provider (glite team) and unfortunately it never received the proper attention of other players. what we have as of Today is an old draft NOT corresponding to the sever-side implementations out in production and a review made by NorduGrid. I wouldn't claim that there is an OGF WG agreement over the glue ldap rendering. But, the most important thing is this: fortunately glue 2 ldap is only deployed on the server side, there are publishers with glue2 data out BUT very little if none has happened on the information consuming side: it is still the right time to fix the problems that came up during the implementation phase.
If Nordugrid want to develop a completely new implementation they should start a new document.
no, nordugrid does not want to develop a new implementation. nordugrid would like to clean up the ldap rendering and submit a consistent redndering document for OGF standardization. bye, Balazs
Balazs Konya [mailto:balazs.konya@gmail.com] On Behalf Of Balazs
Konya said: as far as i know this is the first real review of the old draft. the original version was prepared in a big hurry by a single technology provider (glite team) and unfortunately it never received the proper attention of other players.
It wasn't done in a hurry, we discussed it in public over several months. You could have participated but you chose not to. The decisions were agreed by those who did participate, mainly me, Laurence, Maarten Litmaath and David Horat, and no-one, including you, disagreed. That seems like a clear consensus to me. Your objective seems to be to change the document to retrospectively make the BDII non-compliant. I don't think that's legitimate, and as far as EGI is concerned it's also irrelevant - the deployment of the existing implementation is essentially complete and that isn't going to change regardless of what the GLUE WG decides, it is simply not possible to make substantive changes at this point. Stephen
hi, On 9/19/2012 12:08 PM, stephen.burke@stfc.ac.uk wrote:
It wasn't done in a hurry, we discussed it in public over several months. You could have participated but you chose not to. The decisions were agreed by those who did participate, mainly me, Laurence, Maarten Litmaath and David Horat, and no-one, including you, disagreed.
that is just glite. it is a single technology provider. yes, ARC at that time did not participate in the ldap discussion because we concentrated on the xml rendering. but when we tried to follow the old draft for ldap rendering we run into problems in ARC. Also discovered that not even the deployed glite implementations follow the old draft. This clearly indicates that the old draft requires an update before it can be submitted to OGF pipeline. So, we carried out a thorough review and update of the ldap rendering document. but: instead of discussing the past, i'd like to look forward and discuss how to progress with the ldap rendering document.
That seems like a clear consensus to me.
it seems to me like a clear lack of involvement from other technology providers
Your objective seems to be to change the document to retrospectively make the BDII non-compliant. I don't think that's legitimate, and as far as EGI is concerned it's also irrelevant - the deployment of the existing implementation is essentially complete and that isn't going to change regardless of what the GLUE WG decides, it is simply not possible to make substantive changes at this point.
the old bdii-centric rendering document/approach is not suitable for other mw providers (ARC, UNICORE). This became obvious when the BDII integration tests started. You still did not explain my why it would not be possible to make changes in the glue2 ldap deployment in EGI. Let me know which GLUE2 consumer from EGI (operation) would be broken. bye, Balazs
Balazs Konya [mailto:balazs.konya@gmail.com] On Behalf Of Balazs
Konya said: that is just glite. it is a single technology provider. yes, ARC at that time did not participate in the ldap discussion because we concentrated on the xml rendering.
Indeed. glite were at the time the only group interested in LDAP, so we made decisions, implemented them and deployed them. We now have three years of experience and we haven't encountered any major problems. As I've said several times, if ARC and Unicore really must have a different implementation there's nothing preventing you defining an alternative rendering.
it seems to me like a clear lack of involvement from other technology providers
I don't see how that can be helped - if the other providers chose not to be involved that was their decision.
You still did not explain my why it would not be possible to make changes in the glue2 ldap deployment in EGI. Let me know which GLUE2 consumer from EGI (operation) would be broken.
Maybe there's a basic misunderstanding about the reality of software deployment in EGI. If EMI were to release a new schema in EMI 3 it would likely be 2-3 years at least before all the 4000 or so services where it's currently deployed get updated - we started deploying the current implementation in 2009 and we're only now completing that. That means that changes can only be made in a backward-compatible way - anything new must be able to co-exist with the existing software in arbitrary combinations without breaking anything, and it will be a long time before you can rely on any new features. From an EGI perspective the implementation is finished and deployed and we have to make it work *now*, as it is. If there are imperfections we have to work around them. If people want to discuss changes to be made several years down the line that's fine, but it's a completely separate question. Stephen
participants (5)
-
Andre Merzky -
Balazs Konya -
Florido Paganelli -
Shiraz Memon -
stephen.burke＠stfc.ac.uk