On Wed, Sep 15, 2010 at 04:49:32PM +0100, Michael Hanselmann wrote: > Am 25. August 2010 17:48 schrieb Michael Hanselmann <[email protected]>: > > --- a/doc/design-2.3.rst > > +++ b/doc/design-2.3.rst > > -If an opcode is deferred, the job should stay in the "waitlock" status. > > -Technically it's waiting to acquire its locks. > > +If an opcode is deferred, the job will go back to the "queued" status, > > +even though it's just waiting to try to acquire its locks again later. > > 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. > 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. thanks, iustin
