[glue-wg] Draft on CSV Enumeration was Re: Platform_t

Fri Jun 14 07:06:42 EDT 2013

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 at 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 at 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 at REMOVE_THIShep.lu.se
>>> ==================================================
>>> _______________________________________________ glue-wg mailing
>>> list glue-wg at 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 at REMOVE_THIShep.lu.se
==================================================