[gin-info] Possible list of subset data for info interop

[Oxana Smirnova]

Hi,

I have a question: how a subcluster is different from a queue? Why would 
anybody have a queue spanning several subclusters? I can easily imagine 
an inverse situation: a "subcluster" hosting different queues, but then 
the information that some queues belong to one subcluster and other 
queues - to another, is redundant. Subcluster properties then simply 
become queue properties, no need to introduce a new entity.

Some other points:

- indeed, mentioning GRAM makes no sense for sites that don't use GRAM. 
However, an attribute that describes the job submission interface is 
needed - which may be or may be not GRAM

- some attribtes in Jenny's note are admitedly TG-specific, like unique 
IDs. Since we aim to be schema-independent, we also must be 
infrastructure-independent. Thus I'd like to drop "Unique queue ID", 
"Unique Cluster ID" and "Host Unique ID" from the *common* schema.

- I don't really understand the meaning and necessity of the "Host" class.

- For matchmaking, it is important to know memory available per 
processor, this is something that proved very important for many HEP 
applications

- For many attributes, there is no unique/standard way of representing 
the values: e.g., LRMS version, OS type, processor type are free-text 
strings (are they?), and things like time, RAM, processor speed etc can 
be measured in different units. We have to agree on the common set of 
units and enumerations, if any client is ever going to make use of the 
published information. The JSDL paper is a good start in this respect, I 
suppose.

- Last, but not least: policies at sites are very often establshed per 
user, not only per queue. For example, a user may have max. of only 5 
jobs in a queue that has max. 500 jobs. Thus his/her job nr.6 should not 
be scheduled elsewhere, if one would like to optimize the workload. The 
proposed schema does not reflect per-user quotas at all, which will 
definitely affect scheduling. I can post a list of per-user attributes, 
if people are interested.

Cheers,
Oxana


JP Navarro пишет:
> What about subclusters?
> 
> It's not unusual for one cluster to have nodes with different hardware
> configurations: processor architectures, memory sizes, I/O capabilities,
> networking capabilities, etc.  Clusters can also have nodes with  different
> software configurations.
> 
> Without a notion of a subcluster, users or software have to sift thru a
> large list of individual node properties to determine which nodes meet
> requirements.  While this is sometimes necessary, adding the concept of
> homegeneous subcluster can make resource selection much simpler for
> both users and software.
> 
> JP
> 
> On Mar 1, 2006, at 10:49 AM, Dr. Thomas Soddemann wrote:
> 
>> Hi again,
>>
>> I tried to put most things into an UML diagram. Some classes will  
>> have to be filled, still.
>>
>> <gin-info.png>
>>
>> What am I missing?
>> - I do not have any references to a GRAM.
>>
>> Anything else?
>> Btw: What are the host data?
>>
>> Cheers,
>> Thomas
>>
>> Jennifer M. Schopf wrote:
>>
>>> Thomas-
>>>
>>>    I specifically put that list out as a set of attributes not as  
>>> anything bound to GLUE or CIM so we could pick the information to  be 
>>> communicated in a schema-neutral way. The pieces should be  looked at 
>>> in that way, not as being categorized or grouped really.  If you'd 
>>> like to pull pieces out or group them differently than i  have below 
>>> that's fine.
>>>
>>> The total counts were something TG needed, and many users request  - 
>>> and in fact we come up with them in MDS by adding up other  
>>> attributes, not by having it reported natively. I'm trying to  
>>> separate out the data we need and the implementation of how it's  
>>> achieved.
>>>
>>> We grouped things into subcluster data because that's how people  are 
>>> using the data - no one wants to wade through 1,000 nodes of  
>>> information. That's why those attributes are there for our work  with 
>>> TG. This group may instead decide to only have node data,  which is a 
>>> discussion we should have. I would argue quite strongly  that if we 
>>> want this data to be useful, listing subcluster  attributes will 
>>> help. but perhaps that's a second stage.
>>>
>>> The unique ids really ARE unique in the data we collect from TG -  we 
>>> preface local names with a resource-specific "unique-fying"  
>>> attribute. We need a way to differentiate queue names that are the  
>>> same but at different sites, for example. I would argue quite  
>>> strongly we need unique identifiers associated with all the  components.
>>>
>>>  -jen
>>>
>>>
>>>
>>>
>>>
>>
>> <gin-info.png>
>> <Thomas.Soddemann.vcf>
> 
>