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 ==================================================