[ogsa-wg] Re: [saga-rg] Re: [ogsa-bes-wg] Extensible state model for jobs
Christopher Smith
csmith at platform.com
Wed May 3 12:45:29 CDT 2006
I agree ... we can discuss this next week.
-- Chris
On 03/5/06 10:09, "Thilo Kielmann" <kielmann at cs.vu.nl> 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 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
>>
>
>
More information about the ogsa-wg
mailing list