Am 15. September 2010 19:50 schrieb Iustin Pop <[email protected]>: > On Wed, Sep 15, 2010 at 04:49:32PM +0100, Michael Hanselmann wrote: >> While implementing job priorities I found an issue with this part. >> With the current (e.g. Ganeti 2.2) implementation, a job also goes to >> the “queued” status for a very short amount of time, though this is >> hardly seen. >> >> Jobs can be cancelled whenever they're in the “queued” or “waitlock” >> status (see jqueue.JobQueue.CancelJob). If the job goes back to >> “queued” after any number of opcodes has already been processed, we >> get undefined behaviour if a request to cancel the job comes in. >> Defined behaviour is that a job can only be cancelled before it >> started running. > > Mmm, I don't see a problem with cancelling jobs between opcodes. Well, > it's a documentation problem, but a job can be stopped by many other > reasons. > > I think what you meant is that today we claim a job can't be cancelled, > but it is.
Indeed, yes. Most jobs only have one opcode, where this isn't visible anyway. And even then the period of time in which the job is “queued” again is very short. Depending on incoming job's priorities, this will change in Ganeti 2.3. >> Now the question is: Should cancelling be supported even between >> opcodes or do we have to find another solution? The latter could >> involve a new status, staying in the “waitlock” status as originally >> proposed, or adding more checks (this might also affect other parts of >> the job queue). > > I think we need to change the documentation, saying somethings: we only > guarantee cancelling a job before it starts executing. For multi-opcode > jobs, it's also possible to cancel between opcodes, but we don't > guarantee this. So this is the first option. I'll try to implement it this way (and then update documentation). Michael
