GLUE WG teleconference, Tuesday, April 8, 2014
Greetings GLUE WG, Our next GLUE WG teleconference will be: : Tuesday, April 8, 2014 : 15:30-16:30 Central Europe, 8:30-9:30 AM US Central Teleconference and screen sharing: : https://webconf.vc.dfn.de/ogf-glue-wg/ (Adobe Connect) : Login as Guest using your real name NOTE: we only have one hour! Proposed agenda: 1) Cloud extensions (Salvatore, Warren) March 25th action items:
5) Warren will post to list information on his use of compute entities for clouds and areas he sees/needs improvement 6) Salvatore will post the list the main factors that motivated separate entities rather than leveraging compute entities 7) Salvatore will contact CERN on whether they want to participate in federated cloud discovery effort in the GLUE WG Warren posted glue2 cloud examples March 26. If Salvatore is available we will discuss the factors that motivated separate entities and attempt to reach consensus.
2) LDAP rendering Review Shiraz's and JP's feedback on rendering document and agree on changes to final document: http://redmine.ogf.org/dmsf/glue-wg?folder_id=6569 3) Enumerations (Florido) Review enumeration process Recent recent enumerations discussions Next steps Regards, JP and Shiraz
Meeting notes:
1) Cloud extensions (Salvatore, Warren) March 25th action items:
5) Warren will post to list information on his use of compute entities for clouds and areas he sees/needs improvement 6) Salvatore will post the list the main factors that motivated separate entities rather than leveraging compute entities 7) Salvatore will contact CERN on whether they want to participate in federated cloud discovery effort in the GLUE WG Warren posted glue2 cloud examples March 26. If Salvatore is available we will discuss the factors that motivated separate entities and attempt to reach consensus.
2) LDAP rendering Review Shiraz's and JP's feedback on rendering document and agree on changes to final document: http://redmine.ogf.org/dmsf/glue-wg?folder_id=6569 Agreed to embed the normative LDAP schema in an appendix (based on XML precedence). Action item 1: Florido will clarify the wording on Page 6 based on Shiraz Comment[10]. Action item 2: Florido will upload a new normative schema and e-mail diffs to the list along with a bulleted summary of the changes Action item 3: Shiraz/JP will update authors, embed the schema in the appendix, accept all changes, and share with wg for review Action item 4: Shiraz/JP will submit new document for public comment after one week of wg comment/discussion
3) Enumerations (Florido) Review enumeration process Recent recent enumerations discussions Next steps Everyone provide feedback thru list on Florido's process document Florido will update document with modified format to enable cat'ing of multiple numerations into a single file
Regards,
JP and Shiraz
Hi all, Regarding this: On 2014-04-08 23:24, Navarro, John-Paul F. wrote:
Meeting notes:
[...] 2) LDAP rendering Review Shiraz's and JP's feedback on rendering document and agree on changes to final document: http://redmine.ogf.org/dmsf/glue-wg?folder_id=6569 Agreed to embed the normative LDAP schema in an appendix (based on XML precedence). Action item 1: Florido will clarify the wording on Page 6 based on Shiraz Comment[10]. Action item 2: Florido will upload a new normative schema and e-mail diffs to the list along with a bulleted summary of the changes [...]
Can I have a copy of your revised version of the draft? Is it on redmine somewhere? Otherwise I cannot proceed. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
The latest is in this directory: http://redmine.ogf.org/dmsf/glue-wg?folder_id=6569 called "ogf-glue-2-to-LDAP-v7.2-memon-navarro". JP On May 2, 2014, at 7:20 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
Hi all,
Regarding this:
On 2014-04-08 23:24, Navarro, John-Paul F. wrote:
Meeting notes:
[...] 2) LDAP rendering Review Shiraz's and JP's feedback on rendering document and agree on changes to final document: http://redmine.ogf.org/dmsf/glue-wg?folder_id=6569 Agreed to embed the normative LDAP schema in an appendix (based on XML precedence). Action item 1: Florido will clarify the wording on Page 6 based on Shiraz Comment[10]. Action item 2: Florido will upload a new normative schema and e-mail diffs to the list along with a bulleted summary of the changes [...]
Can I have a copy of your revised version of the draft? Is it on redmine somewhere? Otherwise I cannot proceed.
Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ================================================== _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
Hi all, As a follow up of these tasks: On 2014-04-08 23:24, Navarro, John-Paul F. wrote:
[...]
3) Enumerations (Florido) Review enumeration process Recent recent enumerations discussions Next steps Everyone provide feedback thru list on Florido's process document
An updated version of the enumerations Procedures and Best Practices is here: http://redmine.ogf.org/dmsf_files/13224?download=
Florido will update document with modified format to enable cat'ing of multiple numerations into a single file
The updated versions have been pushed to git-hub with release notes, explanation and the merge script: https://github.com/OGF-GLUE/Enumerations There is still however a lot of work to do. This release does not contain new values, just format changes and better CSV files explanation. Regards, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
An updated version of the enumerations Procedures and Best Practices is here:
"2.1 Services:" You should say that this relates to the ServiceType_t enumeration. "2) Clients SHOULD consider these strings case insensitive." Given that the schema defines them as case sensitive I don't think it's a good idea for clients to do anything different, it's likely to lead to confusion. The reason for preferring lower-case names is precisely to make that easier, but if the enumerations are mixed-case (which we have in some cases for backward-compatibility) then the clients need to preserve that, otherwise queries may fail. "<organization_name> is the reversed domain name of the organization." That probably needs a bit more explanation, something like "a domain associated with the project or organisation which provides or maintains the service". "Presence: MANDATORY for new names" I think that should be RECOMMENDED - there may be exceptions, e.g. where existing names are imported into GLUE. Exceptions should be justified. "Presence: NOT MANDATORY" Should be OPTIONAL. Also the syntax should have square brackets around that part. We may also want to restrict the allowed character set. "Exisiting names not following the above rules can be kept, but should be Deprecated (see Section 4.1)" I don't agree - deprecation implies that a new name should be defined, and in general I don't think that would be worthwhile if the existing name is widely used. "2.2 Interfaces: GFD.147 Appendix B.18 does not define any clear format." This relates to InterfaceName_t. I think the rules can be the same as for ServiceType_t. "2.3 Capabilities: See GFD.147, appendix B.5, on Capability_t." If people are going to define new Capabilities there probably needs to be more guidance on how to do it. There are many more enumerations than just those three - I'm not sure if they're all obvious from the schema doc. At least the OS naming and CPU architecture have caused problems in the past - see https://wiki.egi.eu/wiki/HOWTO05_How_to_publish_the_OS_name https://wiki.egi.eu/wiki/HOWTO06_How_to_publish_the_system_architecture "For EMIR, developed during EMI project that now is over" Even if projects end I think names should normally be preserved. (Also in that particular case the EMI domain still exists at the moment.) It seems fairly unlikely that a new, unrelated (but still Grid-related) project would be created which re-uses a domain name. "Description of the enumeration. This description is a textual, human readable summary of what the object described by the open enumeration does." I think there are in fact two things required - a concise description that will be stored as part of the definition of the enumerated types, and a (usually) longer description that will explain to the WG what the new type is for. "Request for addition/deletion/modification" I'd suggest "deprecation/obsoletion" rather than "deletion" - once names have been defined I think the information should be preserved. I would also suggest a rule that obsolete names can't be re-used for something different, although they could potentially be re-activated for the same use. Stephen -- Scanned by iCritical.
Thanks for the comments Stephen, I agree on most of them. However I'd like to avoid discussing every change by email as I find it dispersive. Would you prefer that I provide a .docx that you can comment on? it helps in meetings to tackle down decisions and track each person's comment, and helps me optimizing the little time I have for GLUE2. Cheers, Florido On 2014-05-03 14:26, stephen.burke@stfc.ac.uk wrote:
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
An updated version of the enumerations Procedures and Best Practices is here:
"2.1 Services:"
You should say that this relates to the ServiceType_t enumeration.
"2) Clients SHOULD consider these strings case insensitive."
Given that the schema defines them as case sensitive I don't think it's a good idea for clients to do anything different, it's likely to lead to confusion. The reason for preferring lower-case names is precisely to make that easier, but if the enumerations are mixed-case (which we have in some cases for backward-compatibility) then the clients need to preserve that, otherwise queries may fail.
"<organization_name> is the reversed domain name of the organization."
That probably needs a bit more explanation, something like "a domain associated with the project or organisation which provides or maintains the service".
"Presence: MANDATORY for new names"
I think that should be RECOMMENDED - there may be exceptions, e.g. where existing names are imported into GLUE. Exceptions should be justified.
"Presence: NOT MANDATORY"
Should be OPTIONAL. Also the syntax should have square brackets around that part. We may also want to restrict the allowed character set.
"Exisiting names not following the above rules can be kept, but should be Deprecated (see Section 4.1)"
I don't agree - deprecation implies that a new name should be defined, and in general I don't think that would be worthwhile if the existing name is widely used.
"2.2 Interfaces: GFD.147 Appendix B.18 does not define any clear format."
This relates to InterfaceName_t. I think the rules can be the same as for ServiceType_t.
"2.3 Capabilities: See GFD.147, appendix B.5, on Capability_t."
If people are going to define new Capabilities there probably needs to be more guidance on how to do it.
There are many more enumerations than just those three - I'm not sure if they're all obvious from the schema doc. At least the OS naming and CPU architecture have caused problems in the past - see
https://wiki.egi.eu/wiki/HOWTO05_How_to_publish_the_OS_name
https://wiki.egi.eu/wiki/HOWTO06_How_to_publish_the_system_architecture
"For EMIR, developed during EMI project that now is over"
Even if projects end I think names should normally be preserved. (Also in that particular case the EMI domain still exists at the moment.) It seems fairly unlikely that a new, unrelated (but still Grid-related) project would be created which re-uses a domain name.
"Description of the enumeration. This description is a textual, human readable summary of what the object described by the open enumeration does."
I think there are in fact two things required - a concise description that will be stored as part of the definition of the enumerated types, and a (usually) longer description that will explain to the WG what the new type is for.
"Request for addition/deletion/modification"
I'd suggest "deprecation/obsoletion" rather than "deletion" - once names have been defined I think the information should be preserved. I would also suggest a rule that obsolete names can't be re-used for something different, although they could potentially be re-activated for the same use.
Stephen
-- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
participants (3)
-
Florido Paganelli -
Navarro, John-Paul F. -
stephen.burke＠stfc.ac.uk