[glue-wg] CPULoad ExecutionEnvironment

[Laurence Field]

Hi Timo,

The first use case use is job monitoring by the end user. This is 
currently not in the scope of the schema. In terms of the other use 
case, the "load" on a cluster is usually defined by the number of jobs 
in a batch system and the length of the queues rather than the CPUload. 
The CPUload is not really relevant to this choice as it reflect the type 
of applications currently running rather than how busy the batch system is.

Laurence



Timo Baur wrote:
> Hi,
>
> We have end users who want to submit the job and wish to know the load 
> where the job is running
> as well as end users who want to schedule their jobs into clusters or 
> endsystems with low load (as
> there is no metascheduler yet).
> I understand that in an "ideal" Grid there is no need to know this 
> parameter because local
> system administrators should keep track of such things transparently.
> So we are going to extend the schema or keep additional records where 
> needed.
>
> Ty,
>
> Timo
>
> Laurence Field wrote:
>> Hi Timo,
>>
>> What role is the person playing in this scenario? Are they system 
>> administrators who are wanting to know the state of the fabric or are 
>> they the end user who submitted the job and wish to know the load on 
>> the machine where their job is running? Or is the use case something 
>> else?
>>
>> The aim of the Glue Schema is to facility interoperation by agreeing 
>> on an information model between all the players involved.  It is 
>> primarily aimed at use cases that are common. It is not a complete 
>> solution but should provide a core that can be extended to meet grid 
>> specific use cases.  If these use cases turn out to be common these 
>> extensions can be incorporated into the core.  If there are objects 
>> and attributes that are important to you which do not map onto the 
>> schema, it suggests that you will need to make a few grid specific 
>> extensions to meet this use cases.
>>
>>
>> Laurence
>>
>>
>> Timo Baur wrote:
>>  
>>> Hi Laurence,
>>>
>>> our use case is that we have some people that wish to know the 
>>> processorload at the endsystems in a cluster.
>>> For that we still use Host.CPULoad from the old GLUE-Versions. Now 
>>> we tried to map the data we already
>>> have (like Host.CPULoad) into GLUE 2.0.
>>>
>>> I am afraid there won't be a migration path and we will have to get 
>>> rid of a lot of data which can't be mapped
>>> into GLUE 2.0 (respectively still describe it in other words like 
>>> e.g. in GLUE 1.3).
>>>
>>> Timo
>>>
>>>
>>> Laurence Field wrote:
>>>    
>>>> Hi Timo,
>>>>
>>>> What is the use case for requiring to know the CPULoad? The 
>>>> execution environment represents a homogeneous cluster so this 
>>>> value would be the average CPULoad across all the cluster.
>>>>
>>>> Laurence
>>>>
>>>>
>>>> Timo Baur wrote:
>>>>      
>>>>> Hi,
>>>>>
>>>>> we miss an entry CPULoad in the ExecutionEnvironment for type 
>>>>> realnode.
>>>>>  Should this value be placed in the "Used" field ?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Timo
>>>>>
>>>>>
>>>>>
>>>>> Sergio Andreozzi wrote:
>>>>>  
>>>>>        
>>>>>> Dear all,
>>>>>>
>>>>>> in the document repository I've updated the version 23 of the 
>>>>>> GLUE 2.0 Spec. This document contains the merge of all the 
>>>>>> contributions.
>>>>>> http://forge.ogf.org/sf/docman/do/listDocuments/projects.glue-wg/docman.root.drafts 
>>>>>>
>>>>>>
>>>>>> The list of authors and contributors was updated according to the 
>>>>>> participation to the discussion.
>>>>>> Please, let me know if I missed someone.
>>>>>>
>>>>>> There will be probably one more minor update before the GLUE 
>>>>>> sessions at OGF 22, nevertheless you are invited to download and 
>>>>>> read this document and report your feedback.
>>>>>> Consider that data types and unit have all to be revised, 
>>>>>> concentrate on class and properties definitions, multiplicity and 
>>>>>> relationships.
>>>>>>
>>>>>> In the last weeks, we made important progress and if we keep this 
>>>>>> level of activity, we can aim for going public comment in the 
>>>>>> coming weeks after OGF.
>>>>>> I want to thank everybody for the time you have dedicated to this 
>>>>>> activity so far.
>>>>>>
>>>>>> Cheers, Sergio
>>>>>>
>>>>>>
>>>>>>                 
>>>>> _______________________________________________
>>>>> glue-wg mailing list
>>>>> glue-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/glue-wg
>>>>>           
>>>>       
>>
>> _______________________________________________
>> glue-wg mailing list
>> glue-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/glue-wg
>>
>>   
>