[SAGA-RG] SAGA Job State Model

[Mariusz Mamoński]

On 22 March 2010 14:25, Andre Merzky <andre at merzky.net> wrote:
> Quoting [Ole Christian Weidner] (Mar 22 2010):
>>
>> Aloha,
>>
>> what was the reason again *not* to have a "pending" state in the
>> saga job model?
>
> The decision on what states are on the top level of the SAGA state
> model was based on the operations available in the API: only those
> states got added which were explicitely reachable via some API
> method.
>
> A 'Pending' state cannot be reached (or left, depending on
> semantics) by any SAGA API call, thus that is only available as
> state detail, not as top level state.
>
>
>> I'm implementing the third job adaptor (gLite
>> CREAM) for saga and again, I don't know if I should map gLite's
>> "pending" state to saga::job::New or saga::job::Running.
>
> It should go to Running (as almost all substates IMHO).  New is
> usually defined so that a job does not yet have a backend
> representation.  In Pending states however, most middleware do
> already maintain job state.
>
>
>> Most of the middleware API's out there come with a plethora of
>> states (e.g. gLite: 11), but most of them map naturally map to one
>> of the saga job model's states. "Pending" is a state pretty much
>> used by everyone (Condor, PBS, LSF, Globus, gLite, GridSAM) and it
>> really doesn't map to saga's model. IMHO it's a major design flaw
>> - how could this fall through the sieve? Or is there a  reason
>> behind this?
>
> See above.  As you say, there is a plethora of states, and many are
> important for specific use cases.  Other states have been candidates
> for SAGA, such as StageIn and StageOut, or Hold, for all of which
> exist interesting use cases.  But again: it did not seem very useful
> to expose states on the top level which cannot be reached via API
> calls - they are then only useful for informational purposes.  As
> such, they are still available in the state details.
>
> Also, as a last point: the more states we add to SAGA, the more
> difficult it is to map to a specific backend state model (DRMAA,
> AWS, local, ssh and BES come to my mind which do not have a Pending,
> for example).
BES has the PENDING state, DRMAA has QUEDED_ACTIVE, *HOLD states that
all fit into the PENDING state, which means that the job is waiting
for  resources.
>
> Best, Andre.
>
>
>
>> Cheers, Ole
>
> -- Nothing is ever easy.
> --
>  saga-rg mailing list
>  saga-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/saga-rg
>



-- 
Mariusz