[graap-wg] Telecon on 3/21

[Jon MacLaren]

Hi Karl,

Ok, I wasn't at the face-to-face meetings - I should have read the 
minutes.  But then I was out of the loop for a while during those 
times.  But where would someone new to the group pick up this 
information?  It is likely that a new user would read the group 
charter, the use cases, and then the example in the specification.  
Lets look at each of these in turn.

1. If you look at the charter, it only mentions doing advance 
reservation of the resources - doesn't mention job submission.

2. The use cases talk in terms of SNAP, with the reservation that is 
being made by GRAAP being an RSLA.  It also states that TSLAs (i.e. the 
running job) are created when something is submitted (something like) a 
batch queue.

3. And even if you look in Appendix 2 of the specification, you don't 
state whether or not the user needs to do something else to make the 
job "happen".  (The only hint that this might automatically happen is 
that the user specifies many things here, far more than a system would 
need merely to reserve resources - but it's totally implicit.)

So no wonder people are confused...

Why don't you put together a simple informational document that shows 
the process of a user creating a job using WS-Agreement, the staging in 
of files, the execution, and staging out of results.  Something that 
shows all the interactions between the user, the agreement provider, 
the resource manager, etc.  The authors of the spec obviously have very 
clear intentions about this - they should be clearly stated somewhere!

I think that such a document would be very valuable at this point.  It 
could also be a valuable input to the BES group, to show you their 
intent - I didn't pick up on your viewpoint from your presentation in 
Seoul, and I think I was pretty awake at that point (you were lucky 
:-).

The group might also want to consider updating the charter.

Jon.


On Mar 21, 2005, at 4:13 PM, Karl Czajkowski wrote:

> Wow!  I thought we'd discussed this ad nauseum in GRAAP face-to-faces,
> so I neglected to mention it.
>
> I see GRAM as being obsolete once WS-Agreement is available to form
> agreements bearing JSDL terms.  The only bits of GRAM that might
> need to remain are some extended operations or RPs on the Agreement
> itself.
>
> karl
>
>
> On Mar 21, Jon MacLaren loaded a tape reading:
> ...
>> The GRAAP-WG charter does not address job submission.  It addresses
>> resource allocation.  We used advance reservation for computational
>> jobs as a use case.  However, we make clear that the claiming of the
>> resources, i.e. the job submission part of that use case, is not
>> something that the GRAAP-WG would address.
>>
>>> This is why I frame this as a misunderstanding/public relations
>>> problem.  There are not open questions for how WS-Agreement SHOULD
>>> handle jobs except that we haven't publicized the the answers well
>>> enough. :-)
>>
>> I can understand that the decoupling of the resource allocation from
>> the job submission is only one architectural viewpoint.  In private
>> discussions that I've had with non-GGF participants, they have wanted
>> to view the resource allocation, job submission, and job execution as 
>> a
>> single "business transaction".  That's a completely valid viewpoint.
>> However, it is different from the one described in the charter, where
>> we view these as separate concerns.
>>
>> Perhaps this is where people's misconceptions come from.
>>
>> Perhaps you could clarify exactly where you view a GRAM-type protocol
>> fitting in with WS-Agreement?  Perhaps some sort of sequence diagram.
>> Do you envisage the user have a separate interaction with GRAM to
>> create/submit/launch the underlying computational job?
>>
>> Jon.
>
> -- 
> Karl Czajkowski
> karlcz at univa.com
>