[glue-wg] Platform_t

Fri Jun 14 06:11:34 EDT 2013

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