UWS POST PHASE=RUN

Paul Harrison paul.harrison at manchester.ac.uk
Wed Nov 5 11:46:30 CET 2014


On 2014-11 -05, at 10:03, Dave Morris <dave.morris at metagrid.co.uk> wrote:

> On 2014-11-03 12:29, Paul Harrison wrote:
>> The intention was that the parameters could be changed at any time up
>> until the job was in the executing state (so a  QUEUED job can have
>> its parameter values changed, but a job in any of the “terminal”
>> states cannot)  - I will try to make this more explicit in the 1.1
>> draft.
> 
> On 2014-11-04 18:16, Walter Landry wrote:
>> Why do allow modification of parameters?  All of the queuing systems
>> that I have worked with in the past did not allow it.  If you want to
>> modify parameters, you can cancel the old request and submit a new
>> one.  That is essentially what would happen in the back end anyway.
> 
> On 2014-11-04 19:40, Patrick Dowler wrote:
>> It would more of a pain to keep creating new async jobs rather than
>> negotiate over one of them and IMO changing the job can/should be part
>> of the negotiation. This all happens in PENDING phase, before any
>> execution, so there is no cancel per se (client could delete the old
>> job). So this is "pre-queueing".
> 
> I agree with Walter, once a job has been accepted by the server it should no longer be modifiable.
> 
> Allowing the job to be modified while it is still in the PENDING phase is useful, because it provides a way for the client and server to negotiate the details of the job, as described in Pat's example.
> 
> However, allowing the client to modify the details of a QUEUED job, after it has been accepted by the server, causes problems.
> 
> What happens if the client modifies a QUEUED job making it invalid or impossible to execute correctly ?
> 
> What happens if the server allocates different jobs to different queues based on the job parameters.
> 
> Ideally, we should treat the phase change from PENDING to QUEUED or EXECUTING as an explicit acceptance by the server that the parameters are valid and the server is able to execute the job.
> 
> Kind of like signing a contract. Once the phase changes, the contract is signed, the job is accepted and is no longer modifiable.
> 
> The only thing a client should be able to do to a job that is QUEUED or EXECUTING is to cancel it by changing the phase to ABORTED.
> 

Dave you (and others) are absolutely right  - QUEUED jobs should not have any parameters changed either JDL or UWS control parameters apart from the PHASE.

I was wrong above,  not sure what I was thinking as the PENDING state exists precisely as the state where the client still has “control” of the job, but the UWS 1.0 standard does have the phase "before the Phase is set to the executing state” which is rather ambiguous - the intention was before a PHASE=RUN was issued - however, it makes it sound like the QUEUED phase is also allowed - I will alter the wording for 1.1 to make this clearer.

Paul.





More information about the grid mailing list