Hi, The Platform_t enumerated type is supposed to represent the CPU architecture. The values currently in the schema doc were probably defined when we first started working on it in 2007 and I don't think they've ever received much attention. For GLUE 1 our current recommendations for the analogous attribute are here: https://wiki.egi.eu/wiki/HOWTO06 which are slightly different, notably we use x86_64 for what is now our standard architecture (Xeon 64-bit) and also i686 for the 32-bit Xeon. These are being carried over into the GLUE 2 publication: ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=glue objectclass=GLUE2ExecutionEnvironment | grep Platform: | sort | uniq -c 25 GLUE2ExecutionEnvironmentPlatform: amd64 16 GLUE2ExecutionEnvironmentPlatform: i686 5 GLUE2ExecutionEnvironmentPlatform: UNDEFINEDVALUE 1 GLUE2ExecutionEnvironmentPlatform: x84_64 356 GLUE2ExecutionEnvironmentPlatform: x86_64 1 GLUE2ExecutionEnvironmentPlatform: x86_84 (Two typos there ...) I guess the simplest thing is to add those values to the list, but do we want to review it? In particular I guess the phi could well do with a new type, and we may also want to think about GPUs. Stephen PS Is there any progress on the storage of the lists of enumerated types in a downloadable format? -- Scanned by iCritical.
Hi Stephen, These days I am updating InterfaceName_t and Capability_t, and I also got an email from Maria regarding OSFamily_t. I think we should benefit of some of the choices made within EGI and your profile and try to integrate them in official documents. For some of these items there was never a formal decision, so for me adding those you mentioned is perfectly fine. You can see the progress on https://github.com/OGF-GLUE/Enumerations I am in for discussing every change or addition of any sort. I plan to put InterfaceName_t by the end of the week, then given the attention I will do OSFamily and Platform. Cheers, Florido On 06/12/13 14:47, stephen.burke@stfc.ac.uk wrote:
Hi,
The Platform_t enumerated type is supposed to represent the CPU architecture. The values currently in the schema doc were probably defined when we first started working on it in 2007 and I don't think they've ever received much attention. For GLUE 1 our current recommendations for the analogous attribute are here:
https://wiki.egi.eu/wiki/HOWTO06
which are slightly different, notably we use x86_64 for what is now our standard architecture (Xeon 64-bit) and also i686 for the 32-bit Xeon. These are being carried over into the GLUE 2 publication:
ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=glue objectclass=GLUE2ExecutionEnvironment | grep Platform: | sort | uniq -c 25 GLUE2ExecutionEnvironmentPlatform: amd64 16 GLUE2ExecutionEnvironmentPlatform: i686 5 GLUE2ExecutionEnvironmentPlatform: UNDEFINEDVALUE 1 GLUE2ExecutionEnvironmentPlatform: x84_64 356 GLUE2ExecutionEnvironmentPlatform: x86_64 1 GLUE2ExecutionEnvironmentPlatform: x86_84
(Two typos there ...) I guess the simplest thing is to add those values to the list, but do we want to review it? In particular I guess the phi could well do with a new type, and we may also want to think about GPUs.
Stephen
PS Is there any progress on the storage of the lists of enumerated types in a downloadable format?
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ==================================================
Hi Florido, It's great that you're making progress on this. The initial scope we agreed on as I remember was ServiceType_t. I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT. Second, I think the first official release of these enumeration guidelines should be reviewed by glue-wg participants and clearly labeled DRAFT until that review has happened. That broader review is important so that we can have consensus on the way types are being defined. Once we have agreement on the general format and values of initial enumerations, I think making tweaks and modifications can happen without review unless they introduce some significant change. Does this make sense to you? Thanks, JP On Jun 12, 2013, at 8:37 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
Hi Stephen,
These days I am updating InterfaceName_t and Capability_t, and I also got an email from Maria regarding OSFamily_t.
I think we should benefit of some of the choices made within EGI and your profile and try to integrate them in official documents.
For some of these items there was never a formal decision, so for me adding those you mentioned is perfectly fine.
You can see the progress on
https://github.com/OGF-GLUE/Enumerations
I am in for discussing every change or addition of any sort.
I plan to put InterfaceName_t by the end of the week, then given the attention I will do OSFamily and Platform.
Cheers, Florido
On 06/12/13 14:47, stephen.burke@stfc.ac.uk wrote:
Hi,
The Platform_t enumerated type is supposed to represent the CPU architecture. The values currently in the schema doc were probably defined when we first started working on it in 2007 and I don't think they've ever received much attention. For GLUE 1 our current recommendations for the analogous attribute are here:
https://wiki.egi.eu/wiki/HOWTO06
which are slightly different, notably we use x86_64 for what is now our standard architecture (Xeon 64-bit) and also i686 for the 32-bit Xeon. These are being carried over into the GLUE 2 publication:
ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=glue objectclass=GLUE2ExecutionEnvironment | grep Platform: | sort | uniq -c 25 GLUE2ExecutionEnvironmentPlatform: amd64 16 GLUE2ExecutionEnvironmentPlatform: i686 5 GLUE2ExecutionEnvironmentPlatform: UNDEFINEDVALUE 1 GLUE2ExecutionEnvironmentPlatform: x84_64 356 GLUE2ExecutionEnvironmentPlatform: x86_64 1 GLUE2ExecutionEnvironmentPlatform: x86_84
(Two typos there ...) I guess the simplest thing is to add those values to the list, but do we want to review it? In particular I guess the phi could well do with a new type, and we may also want to think about GPUs.
Stephen
PS Is there any progress on the storage of the lists of enumerated types in a downloadable format?
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ================================================== _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
Hi JP, On 06/13/13 23:38, JP Navarro wrote:
Hi Florido,
It's great that you're making progress on this. The initial scope we agreed on as I remember was ServiceType_t.
that was already done and revised with some of the people in this group. I recently received new strings to put in. I didn't contact the group as I think is really of no interest for anybody that I call a meeting for every 3 new strings I receive. If you want next time I can just notify here the changes.
I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT.
Labelling a CSV doc as a draft is a bit tricky. I'll think of a way of doing it. Suggestions: 1) add a preamble to the CSV stating the status. I am not sure one can put comments in a CSV, I will have a look at the format definition. 2) open a second repository called DRAFT for these CSV in such status. Consumers can get these documents the same way they do with the official one (in the MASTER branch) but from the draft branch. Here we're leveraging git and git-hub capability At the moment I only posted Cabilities_t, mostly with entries from GFD147 doc, and adding those produced during EMI. Nobody ever used these capabilities before, to my understanding. Me and Balazs where part of the process so we kept everything tidy (Balazs is actually stricter than me on these matters :) )
Second, I think the first official release of these enumeration guidelines should be reviewed by glue-wg participants and clearly labeled DRAFT until that review has happened. That broader review is important so that we can have consensus on the way types are being defined.
I can post draft guidelines somewhere and attach them to the distributed material in git-hub. I have them written already somewhere, I'll search them back. But, where do I post them? redmine docs?
Once we have agreement on the general format and values of initial enumerations, I think making tweaks and modifications can happen without review unless they introduce some significant change.
Does this make sense to you?
I consider those in GDF147 the initial agreed values. I think we should make the process smoother and faster. It takes to long to do everything with this GLUE2 stuff, and I have the feeling that the technology is already too old to face nowadays challenges. I'd rather publish all that I have and call meetings only if I really find inconsistencies. But I agree with you that guidelines must be accepted. So, Action items: 1) I will mark all the undiscussed material as DRAFT (choosing one of the strategies listed above), but publish all I have 2) I will propose a set of best practices for naming and inclusion of new strings; we discuss that, I attach it to git-hub What do the group thinks?
Thanks,
JP On Jun 12, 2013, at 8:37 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
Hi Stephen,
These days I am updating InterfaceName_t and Capability_t, and I also got an email from Maria regarding OSFamily_t.
I think we should benefit of some of the choices made within EGI and your profile and try to integrate them in official documents.
For some of these items there was never a formal decision, so for me adding those you mentioned is perfectly fine.
You can see the progress on
https://github.com/OGF-GLUE/Enumerations
I am in for discussing every change or addition of any sort.
I plan to put InterfaceName_t by the end of the week, then given the attention I will do OSFamily and Platform.
Cheers, Florido
On 06/12/13 14:47, stephen.burke@stfc.ac.uk wrote:
Hi,
The Platform_t enumerated type is supposed to represent the CPU architecture. The values currently in the schema doc were probably defined when we first started working on it in 2007 and I don't think they've ever received much attention. For GLUE 1 our current recommendations for the analogous attribute are here:
https://wiki.egi.eu/wiki/HOWTO06
which are slightly different, notably we use x86_64 for what is now our standard architecture (Xeon 64-bit) and also i686 for the 32-bit Xeon. These are being carried over into the GLUE 2 publication:
ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=glue objectclass=GLUE2ExecutionEnvironment | grep Platform: | sort | uniq -c 25 GLUE2ExecutionEnvironmentPlatform: amd64 16 GLUE2ExecutionEnvironmentPlatform: i686 5 GLUE2ExecutionEnvironmentPlatform: UNDEFINEDVALUE 1 GLUE2ExecutionEnvironmentPlatform: x84_64 356 GLUE2ExecutionEnvironmentPlatform: x86_64 1 GLUE2ExecutionEnvironmentPlatform: x86_84
(Two typos there ...) I guess the simplest thing is to add those values to the list, but do we want to review it? In particular I guess the phi could well do with a new type, and we may also want to think about GPUs.
Stephen
PS Is there any progress on the storage of the lists of enumerated types in a downloadable format?
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ================================================== _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ==================================================
Hi all, It seems that CSV format has no comments. http://tools.ietf.org/html/rfc4180 So for the moment being I'll go the easyest way, one more way than I suggested in my previous mail, that is, appending a -draft to the filenames. e.g.: Capability_t.csv becomes Capability_t-draft.csv Cheers, Florido On 06/14/13 12:11, Florido Paganelli wrote:
Hi JP,
On 06/13/13 23:38, JP Navarro wrote:
Hi Florido,
It's great that you're making progress on this. The initial scope we agreed on as I remember was ServiceType_t.
that was already done and revised with some of the people in this group. I recently received new strings to put in. I didn't contact the group as I think is really of no interest for anybody that I call a meeting for every 3 new strings I receive. If you want next time I can just notify here the changes.
I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT.
Labelling a CSV doc as a draft is a bit tricky. I'll think of a way of doing it. Suggestions:
1) add a preamble to the CSV stating the status. I am not sure one can put comments in a CSV, I will have a look at the format definition.
2) open a second repository called DRAFT for these CSV in such status. Consumers can get these documents the same way they do with the official one (in the MASTER branch) but from the draft branch. Here we're leveraging git and git-hub capability
At the moment I only posted Cabilities_t, mostly with entries from GFD147 doc, and adding those produced during EMI. Nobody ever used these capabilities before, to my understanding. Me and Balazs where part of the process so we kept everything tidy (Balazs is actually stricter than me on these matters :) )
Second, I think the first official release of these enumeration guidelines should be reviewed by glue-wg participants and clearly labeled DRAFT until that review has happened. That broader review is important so that we can have consensus on the way types are being defined.
I can post draft guidelines somewhere and attach them to the distributed material in git-hub.
I have them written already somewhere, I'll search them back. But, where do I post them? redmine docs?
Once we have agreement on the general format and values of initial enumerations, I think making tweaks and modifications can happen without review unless they introduce some significant change.
Does this make sense to you?
I consider those in GDF147 the initial agreed values. I think we should make the process smoother and faster. It takes to long to do everything with this GLUE2 stuff, and I have the feeling that the technology is already too old to face nowadays challenges.
I'd rather publish all that I have and call meetings only if I really find inconsistencies.
But I agree with you that guidelines must be accepted. So,
Action items:
1) I will mark all the undiscussed material as DRAFT (choosing one of the strategies listed above), but publish all I have
2) I will propose a set of best practices for naming and inclusion of new strings; we discuss that, I attach it to git-hub
What do the group thinks?
Thanks,
JP On Jun 12, 2013, at 8:37 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
Hi Stephen,
These days I am updating InterfaceName_t and Capability_t, and I also got an email from Maria regarding OSFamily_t.
I think we should benefit of some of the choices made within EGI and your profile and try to integrate them in official documents.
For some of these items there was never a formal decision, so for me adding those you mentioned is perfectly fine.
You can see the progress on
https://github.com/OGF-GLUE/Enumerations
I am in for discussing every change or addition of any sort.
I plan to put InterfaceName_t by the end of the week, then given the attention I will do OSFamily and Platform.
Cheers, Florido
On 06/12/13 14:47, stephen.burke@stfc.ac.uk wrote:
Hi,
The Platform_t enumerated type is supposed to represent the CPU architecture. The values currently in the schema doc were probably defined when we first started working on it in 2007 and I don't think they've ever received much attention. For GLUE 1 our current recommendations for the analogous attribute are here:
https://wiki.egi.eu/wiki/HOWTO06
which are slightly different, notably we use x86_64 for what is now our standard architecture (Xeon 64-bit) and also i686 for the 32-bit Xeon. These are being carried over into the GLUE 2 publication:
ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=glue objectclass=GLUE2ExecutionEnvironment | grep Platform: | sort | uniq -c 25 GLUE2ExecutionEnvironmentPlatform: amd64 16 GLUE2ExecutionEnvironmentPlatform: i686 5 GLUE2ExecutionEnvironmentPlatform: UNDEFINEDVALUE 1 GLUE2ExecutionEnvironmentPlatform: x84_64 356 GLUE2ExecutionEnvironmentPlatform: x86_64 1 GLUE2ExecutionEnvironmentPlatform: x86_84
(Two typos there ...) I guess the simplest thing is to add those values to the list, but do we want to review it? In particular I guess the phi could well do with a new type, and we may also want to think about GPUs.
Stephen
PS Is there any progress on the storage of the lists of enumerated types in a downloadable format?
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ================================================== _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ==================================================
On Jun 14, 2013, at 5:11 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
<snip> Labelling a CSV doc as a draft is a bit tricky. I'll think of a way of doing it. Suggestions:
1) add a preamble to the CSV stating the status. I am not sure one can put comments in a CSV, I will have a look at the format definition.
2) open a second repository called DRAFT for these CSV in such status. Consumers can get these documents the same way they do with the official one (in the MASTER branch) but from the draft branch. Here we're leveraging git and git-hub capability
I like this approach.
<snip> I can post draft guidelines somewhere and attach them to the distributed material in git-hub.
I have them written already somewhere, I'll search them back. But, where do I post them? redmine docs?
The README.txt where the enumerations are seems like a good place. Thanks, JP
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of JP Navarro said: I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT.
I'm not exactly sure what you want to label as DRAFT - the enumerated values themselves, the publication method or the procedures? For the actual values I don't think calling them drafts would make much sense. On one side they are constantly growing so will always be drafts. On the other hand, for values defined in the schema doc or which are already in use they can't just be changed arbitrarily, we would need a good reason and a deprecation procedure - in practice there could be a long period with both old and new values being published so it isn't something to do lightly. Stephen -- Scanned by iCritical.
On 06/14/13 13:11, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of JP Navarro said: I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT.
I'm not exactly sure what you want to label as DRAFT - the enumerated values themselves,
no
the publication method
yes
or the procedures?
yes For these above I just need to state ' this si a draft' somewhere in the text. But JP suggests we should have a draft status also for the CSV files that have: 1) values that differ from GFD147 AND 2) that we did not discuss within the group. that is, all CSV files but ServiceType_t.csv Since .csv files do not support comments, I need to mark their statuses in some other way, like I explained in the previous email.
For the actual values I don't think calling them drafts would make much sense. On one side they are constantly growing so will always be drafts.
Agree
On the other hand, for values defined in the schema doc or which are already in use they can't just be changed arbitrarily, we would need a good reason and a deprecation procedure - in practice there could be a long period with both old and new values being published so it isn't something to do lightly.
Agree -- that's why we use deprecated or obsolete. For ServiceType_t we had this discussion before, and all the participants decided together, so I have no intention to discuss that again for now. So that would be the only non-draft document. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se ==================================================
If all we're publishing are the values that someone in the GLUE community has used, and which the GLUE WG has not made any attempt to reconcile for consistency, duplication, formatting, community meaningful names (not misleading), etc. then it would not make sense to review them. In that case our procedure should be anyone can add values and we will not question them. However, I think we're aiming for a slightly higher bar, although we all agree that reviewing every single value would not be productive. My suggestion is that our INITIAL release of enumerations for a specific type be reviewed by the group. Florido, or whomever is proposing the initial DRAFT set, should write-up brief guidelines we're trying to follow for that type. After the group agrees on the guidelines and on change to the initial set we release them. Any new enumerations that are submitted and consistent with the guidelines are simply added without discussion. What do other think? JP On Jun 14, 2013, at 6:11 AM, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of JP Navarro said: I think we should discuss other Enumerations and get consensus before we start publishing them, or they should be labeled as DRAFT.
I'm not exactly sure what you want to label as DRAFT - the enumerated values themselves, the publication method or the procedures? For the actual values I don't think calling them drafts would make much sense. On one side they are constantly growing so will always be drafts. On the other hand, for values defined in the schema doc or which are already in use they can't just be changed arbitrarily, we would need a good reason and a deprecation procedure - in practice there could be a long period with both old and new values being published so it isn't something to do lightly.
Stephen
-- Scanned by iCritical.
JP Navarro [mailto:navarro@mcs.anl.gov] said:
If all we're publishing are the values that someone in the GLUE community has used, and which the GLUE WG has not made any attempt to reconcile for consistency, duplication, formatting, community meaningful names (not misleading), etc. then it would not make sense to review them.
You seem to be treating this as something which we're starting now. In fact several of the enumerated types are carried over from GLUE 1 where we have ten years or more of discussion and agreement, and even for things new or different in GLUE 2 we've been discussing since 2007 and the things in the schema doc were finalised in 2009. We also have many of them implemented in the EMI software releases over the last couple of years. It's fair to say that some things have received a lot more attention than others, but we're certainly not starting from a blank slate. The thing that's new here is to have downloadable lists which are kept up to date, and a (hopefully lightweight) procedure for registering changes. Stephen -- Scanned by iCritical.
Stephen, You're right in that I may not be fully aware of previous work, however, I do think it's appropriate to look over GLUE 1 enumerations before recommending them in the context of GLUE 2. The same applies to EMI or other implementations. We want to bring the best of previous standards work and of current implementations, and as a community endorse the parts that we believe should be standard or recommended broadly. You're right that a lot of good work has been done and we want to built on it. Thanks, JP On Jun 14, 2013, at 8:15 AM, stephen.burke@stfc.ac.uk wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
If all we're publishing are the values that someone in the GLUE community has used, and which the GLUE WG has not made any attempt to reconcile for consistency, duplication, formatting, community meaningful names (not misleading), etc. then it would not make sense to review them.
You seem to be treating this as something which we're starting now. In fact several of the enumerated types are carried over from GLUE 1 where we have ten years or more of discussion and agreement, and even for things new or different in GLUE 2 we've been discussing since 2007 and the things in the schema doc were finalised in 2009. We also have many of them implemented in the EMI software releases over the last couple of years. It's fair to say that some things have received a lot more attention than others, but we're certainly not starting from a blank slate. The thing that's new here is to have downloadable lists which are kept up to date, and a (hopefully lightweight) procedure for registering changes.
Stephen
-- Scanned by iCritical.
participants (3)
-
Florido Paganelli -
JP Navarro -
stephen.burke＠stfc.ac.uk