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

[Thilo Kielmann]

Chris and Andre,

I think we really should resolve this issue face-to-face next week at GGF17.
That will save a lot of email typing time...

Andre, do we have a slot in one of our sessions?


Thilo

On Wed, May 03, 2006 at 06:08:46PM +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 18:08:46 +0200
> From: Andre Merzky <andre at merzky.net>
> To: Christopher Smith <csmith at platform.com>
> Cc: Andre Merzky <andre at merzky.net>,
> 	"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 03 2006):
> > 
> > On 03/5/06 05:36, "Andre Merzky" <andre at merzky.net> wrote:
> > 
> > > 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.
> > > 
> > The state that a job enters after a create_job operation is 'pending', so
> > the create_job operation is the method that puts a job in this state.
> 
> Right, I understand that from the queuing point I think.
> However, from the application level it does not matter, as
> it cannot actively change that state.  We have no notion of
> queue states at all.
> 
> Well, let me put it differently: what do we gain by moving
> the state to the higher level?  It complicates the state
> diagram (not much, that is not the point), but does not
> allow to perform any new state transition from application
> level.
> 
> As said, I would compare this to Suspended state: its
> clearly an important state in many systems, but as long as
> the API does not expose means to suspend/resume a job, the
> state is meaningless, and merily informative (e.g. the job
> gut suspended by a 3rd party, or by the backend).  That
> information is exposed however, through the job state
> details - same holds for hols (ha!) I think.
> 
> 
> > This state is required for queuing systems ... I can't even imagine how it
> > got dropped from the state diagram. I think you're trying to map the task
> > state model too closely. ;-)
> 
> Nono, that has nothing to do with the task states - they
> could easily leave that state out.  Well, its very
> convenient to have the same model here, thats for sure ;-)
> 
> 
> > > 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.
> >
> > This I agree with.
> 
> As said, it might well be that SAGA is broken in the respect
> that we doesn't allow job.hold (), or submit into hold.
> Well, it wasn't in the use-cases ... :-P  
> 
> Cheers, Andre.
> 
> 
> > -- Chris
> 
> 
> 
> -- 
> "So much time, so little to do..."  -- Garfield
> 



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