[rm-wg] Some Questions :o)

[Strong, Paul]

Hi Laurence,

So, if I understand correctly, the management abstractions behind the
Service are only important in that...

1)   The Job must have a way of expressing it's dependencies - that is
what binaries it may need, what data it may need, what types of CPU it
can run on etc.  JSDL can supply this - right?
2)   The Job must have a way of expressing the desired service level
objectives, for example desired completion time (absolute), maximum job
duration, maximum % of resources to be consumed and so forth.
3)   The User must be able to get monitoring information and results
from the service that include progress versus service level, resources
consumed versus share and so forth.

This brings us back to what Dave was suggesting about drilling down on
Share (to some degree).   The area to be refined is perhaps more on the
side of the interaction of the user with the service and between the two
organizations.  For example when submitting the Job and querying
progress of the Job.  Examples -

1)	Do Users simply know what services they can access based on a
set of Shares or agreements already in place between their organization
and the Admin Domain?   Do they poll services (that are presumably
advertized) to see which ones they have shares with and which have spare
capacity?  Or can they dynamically negotiate access/Shares and so forth?
2)	How complete or self contained does the job submission have to
be? Thus is it simply a request for a binary already installed and made
available by the service or can the submission include the binary and
instructions on how this should be deployed? :o)   This makes a big
difference in terms of the level of detail that needs to be exposed by
the Service and expressed in the Share concept.

Cheers
Paul

-----Original Message-----
From: Laurence Field [mailto:Laurence.Field at cern.ch] 
Sent: Wednesday, July 25, 2007 5:19 AM
To: Strong, Paul
Cc: Sergio Andreozzi; Sergio Andreozzi; rm-wg at ogf.org; Balazs Konya
Subject: Re: Some Questions :o)

Hi Paul,

 From the perspective of the consuming organisation (we need to think of
a better term) it stops at step 3.  We delegate the responsibility for
carrying out the activity to the service.  We know that we have a share
of the resource which the service manages and have described our
activity.  How the service does this is of no concern to us. What does
concern us is that the service ensures that our activity is completed
correctly.

I will try to come up with a sequence diagram for the Workload and Data
Management scenarios.

I quite like the direction all this is taking and the diagrams seem to
make sense in many places. I especially like the concept of the
activity.


Laurence




Strong, Paul wrote:
>
> 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.
>
>
>