[rm-wg] Some Questions :o)

[Strong, Paul]

Hi Sergio,

I have taken the liberty of perhaps suggesting a slightly different
breakdown (see attached).  This is based on the following workflow

1.	A consuming Organization agrees one or more Share(s) with an
Admin Domain for the access to a Computing Service.  That Service may
comprise a set of Compute Resources and Application Resources.  Share
could include types of resources, quantities, achievable SLOs and so
forth.
2.	The Admin Domain delegates responsibility for delivering a
specific Share to a specific Computing Service.
3.	A User within the consuming Organization then submits a Job to
the Computing Service.  The Job request includes target resource types
(application types, cpu types?) and desired quantities and so forth
4.	The Computing Service checks to see if the Job request can be
fulfilled by matching the Job request details to available Resources
under it's management.
5.	If the Job can be fulfilled the Service creates a logical
Container and maps the Job to it.  In reality, this may mean associating
an Application Resource with a Computing Resource and then the pair to
the Job.  The Container is a useful abstraction as other resources may
be added later.

Whilst I think this is probably nowhere near perfect, I think that
enumerating your use case and sequence diagram in a way similar to the
above will make this exercise much quicker.  

In this the Element becomes a Container, which can make use of various
resources, for example physical machines, virtual servers, application
binaries, data and so forth, thus providing an execution environment.
The Container is created on demand when a Job is accepted, based on the
resources that the Service has available to it, the resource types and
quantities requested by the job and the resource types and quantities
still available from the share.





-----Original Message-----
From: Sergio Andreozzi [mailto:sergio.andreozzi at cnaf.infn.it]
Sent: Thursday, July 19, 2007 5:56 PM
To: Strong, Paul
Cc: Laurence; Sergio Andreozzi; rm-wg at ogf.org; Balazs Konya
Subject: Re: Some Questions :o)

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/UseCases
ForTheComputingElement?_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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLUE Admin Domains.gif
Type: image/gif
Size: 14550 bytes
Desc: GLUE Admin Domains.gif
Url : http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLUE Core.gif
Type: image/gif
Size: 36537 bytes
Desc: GLUE Core.gif
Url : http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLUE Derived Classes 1.gif
Type: image/gif
Size: 50193 bytes
Desc: GLUE Derived Classes 1.gif
Url : http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment-0007.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLUE Derived Classes 2.gif
Type: image/gif
Size: 14990 bytes
Desc: GLUE Derived Classes 2.gif
Url : http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLUE Relationships.gif
Type: image/gif
Size: 74619 bytes
Desc: GLUE Relationships.gif
Url : http://www.ogf.org/pipermail/rm-wg/attachments/20070725/73b54829/attachment-0009.gif