On Mar 22, 2010, at 8:25 AM, Andre Merzky 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.
Ok, but why? This is IMHO a pretty random decision.
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.
What about saga::job::New --run()--> saga::job::Pending. Also, you could say the same thing about Done and Failed: these states are not explicitly reachable via a call... and wait() doesn't really count! if it does, you could also use it to transition from Pending to Running, Failed, etc.
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.
Usually?
In Pending states however, most middleware do already maintain job state.
What do you mean by maintaining a 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.
But again: why didn't it seem very useful? ;-) I would be perfectly happy using the state detail. The only problem with them is that they're absolutely useless without any formalization. Do you think it would make sense to define an extended state model (on implementation level) for the state details? This is IMHO the only way to make use of it programatically.
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).
I don't think that this is a valid point. Why does it become more difficult? Especially if we're talking about a state that cannot be reached explicitly: you don't have to worry about it at all. If SSH doesn't have a "PENDING" state, it will simply never reach it!
Best, Andre.
- Ole
Cheers, Ole
-- Nothing is ever easy.