[rm-wg] Some Questions :o)

[Sergio Andreozzi]

Hi Paul,

Strong, Paul wrote:
> I have been going through the GLUE 2 doc and have a number of questions.

great... some comments inline

>    1. Site - Firstly I would strongly suggest renaming to AdminDomain. 
>       More specifically, clearly an admin domain can span multiple
>       physical locations (which is why site could be a confusing name),
>       the question I have is does an admin domain have a 1 to 1 mapping
>       with a real organization, or can an organization have multiple
>       admin domains (my guess would be yes) and can multiple
>       organizations present a single admin domain (think a consortium,
>       or perhaps that consortium is it's own organization).

your proposal matches the naming of CIM if I'm right. As regards the 
mapping, your guess is right, the relationship is many-to-many between 
admin domain and real organizations. We have use cases for all the 
combinations.

>    2. I am still very unclear as to the value of Element (Figure 3).  It
>       is an aggregation, but what problem does it solve - management? 

this is actually one of the open issues; not everybody agree on it

>       Am I right in assuming that this is actually the "container" for a
>       job?  If so is it genuinely managed such that you do not need to
>       manage the other elements?  

at the moment, it represents a way to identify via a persistent name the 
concepts that together offer a computing functionality in a Grid.

if you consider this example:
https://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/UseCasesForTheComputingElement?_message=1184893697976

all the concepts are necessary to offer the computing functionality;  we 
aggregate all of them and identify by the concept of computing element;

at the moment there are two opinions in the GLUE WG: one is to remove 
the computing element concept and to associate both computing service 
and computing resource to the admin domain; the other is to use the 
computing element as a way to identify these entity and associate it to 
the admin domain

>       The composed of relationship implies
>       exclusive membership and it would seem to me that most of the
>       components that comprise the element can and will be managed out
>       of the context of the ComputeElement.   Actually, more correctly -
>       do compute resources and services share the same life - are they
>       created and destroyed when the element is? 

as regards the lifetime, I agree that the composition relationship is 
too strong; it could be replaced with an aggregation relationship;

here at DMTF I got the hint that the computing element could be an admin 
domain as well, and that admin domains in CIM are composable.

>    3. Figure 4 - it seems ot me that the ComputingService
>       abstracts Computing Resources.  Shares seem to define a virtual
>       computing resource, i.e. some part of a resources.  Althought the
>       rest of the text iindicates that it is a utilization target.  If
>       so, t would seem that it is a policy.  It seems to me that both
>       concepts are useful.

it could be considered as a "view" on the resources or as an SLA with 
status information on the current usage.

> I have to admit that 2 things would really help me understand this 
> better.  The first would be a sequence diagram that shows the various 
> interactions.  The second is a text use case.

I will work on the sequence diagram, for the text use case you can 
consider the one I mention above for the short term; a more detailed 
example will come

> Let me give you my (probably distorted :o) view of what I think you are 
> trying to build.
>  
> i)    You want to provide services that are admin domain specific and 
> that can be shared.
> ii)    You want these services to execute jobs submitted from anywhere 
> within an authorized virtual organization to be run on the 
> resources within the admin domain, that have been assigned to that service.
more VO's can be authorized to the use the same service, different 
share; authorization can be also per group/role (sub-structures of VO's)

> iii)    Each job is executed within a container, that the service 
> creates specifically for that job when the job is submitted.
can you clarify what do you mean by container in this context?

> iv)    The container includes all of the resources (compute, data, 
> application etc.) required by the job to execute.  (Is Share the scalar 
> value of one of the "sides" of the container?)

> v)    There are consumer and supplier side service level policies 
> associated with the job and its container.  One would be a policy 
> defining the target utilization of a resource, thus you would want to 
> run one or more jobs (and thus containers) either sequentially or in 
> parallel in order to meet the target utilization.  Another could be a 
> consumer side request for "sizing" the container, ie saying I need X 
> cpus for the life of the job, or I need Y cpu-minutes for the job
>  
> Anyway I think it is the nature of v) that is confusing.

the typical situation is that of an admin domain exposing a computing 
farm to a Grid infrastructure via a Grid interface. Consumers (VO's) 
would sign a contract with the admin domain in order to create a share 
for its users. As you point out, shares contain different types of 
policy: authorization policies for users submitting the jobs, mapping 
policies for resources depending on the service that is required by your 
consumers, other policies can apply to jobs (e.g., max wall time).

Shares can be used in many ways, e.g., you can create a share to handle 
short jobs (small MaxWallTime) so that they don't get stuck by long jobs 
activity; another possibility is shares mapping jobs only to fast 
machines (if your farm handles both old and new ones).

> All enlightenment appreciated ;o)

I hope I increased the intensity of light on the topic ;).


Cheers, Sergio