[saga-rg] Re: [ogsa-bes-wg] Extensible state model for jobs

[Thilo Kielmann]

I would suggest to spend some 20 minutes of a SAGA session on this.
Does anyone (Andre? ;-) know which session this could be?


Thilo

On Wed, May 03, 2006 at 02:36:04PM +0200, Andre Merzky wrote:
> X-Original-To: kielmann at localhost
> Delivered-To: kielmann at localhost.cs.vu.nl
> Delivered-To: grdfm-saga-rg-outgoing at mailbouncer.mcs.anl.gov
> X-Original-To: grdfm-saga-rg at mailbouncer.mcs.anl.gov
> Delivered-To: grdfm-saga-rg at mailbouncer.mcs.anl.gov
> Date: Wed, 3 May 2006 14:36:04 +0200
> From: Andre Merzky <andre at merzky.net>
> To: Christopher Smith <csmith at platform.com>
> Cc: "ogsa-wg at ggf.org" <ogsa-wg at ggf.org>, ogsa-bes-wg at ggf.org,
> 	SAGA RG <saga-rg at ggf.org>
> Subject: [saga-rg] Re: [ogsa-bes-wg] Extensible state model for jobs
> 
> Quoting [Christopher Smith] (May 02 2006):
> > 
> > Hi all,
> > 
> > As Marvin mentioned in his email on extensibility and composition of
> > protocols, I'd like to present this short document describing, in more
> > detail, a model for extending the state model of jobs from a "base profile".
> > The document is based on some discussions that Marvin and I have been having
> > about scheduler interoperability, and is very close to the model that has
> > been proposed within the SAGA working group. Please review Marvin's email
> > about extensibility to get a feel for the "context" of the model.
> > 
> > It is my intention to show how the ESI and BES state models can be
> > represented using this approach. I'll try to get that done before Tokyo, but
> > might just need to present some slides at GGF17, assuming I'm given a few
> > minutes to do so.
> > 
> > This is very much a work in progress, so I'm looking forward to feedback....
> > 
> > A note for the SAGA group .... I'd still like to see "pending" in the base
> > job state diagram ... don't know why it disappeared. ;-)
> 
> Right now its absent because only those states which can be
> actually reached by SAGA method calls are present.  Now, as
> you said earlier, it can be assumed a flaw that SAGA has no
> means to put a job into 'Pending' state.  
> 
> So, if there are some use cases or some agreement that the
> API should allow to move a job into 'Pending' state, the
> method/attribute will be added, and the state will be added.
> 
> Similar reasoning holds for 'Suspend' - as long as we don't
> have suspend/resume methods, we would not like to expose a
> 'Suspended' state on the higher level state diagram.
> 
> Well, thats my opinion at least ;-)  I know that you see
> Pending as crucial.  IIUC, that funds (partly) on the fact
> that most/all Queuing systems support pending.  However,
> SAGA is right now not about submissing to queues in the
> first place, so I am not sure if that is relevant (right
> now).  
> 
> Could we discuss that in Tokyo?  Some (real) use cases would
> be very convincing.
> 
> Thanks, best regards, 
> 
>   Andre.
> 
> 
> > -- Chris
> 
> -- 
> "So much time, so little to do..."  -- Garfield
> 



-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/