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

3 May 2006


      I agree ... we can discuss this next week.

-- Chris


On 03/5/06 10:09, "Thilo Kielmann"  wrote:
...
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@localhost
Delivered-To: kielmann@localhost.cs.vu.nl
Delivered-To: grdfm-saga-rg-outgoing@mailbouncer.mcs.anl.gov
X-Original-To: grdfm-saga-rg@mailbouncer.mcs.anl.gov
Delivered-To: grdfm-saga-rg@mailbouncer.mcs.anl.gov
Date: Wed, 3 May 2006 18:08:46 +0200
From: Andre Merzky 
To: Christopher Smith 
Cc: Andre Merzky ,
"ogsa-wg@ggf.org" , ogsa-bes-wg@ggf.org,
SAGA RG 
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"  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