>
> > If needed, we could add some priority handling in the queue itself, but I
> > think a better plan is to maintain a debian and a lp canaris that will just
> > suspend the execution of imports when one of the sites is down (and kill and
> > requeue the ones in progress at the top of the queue)
>
> I think the canaries are a good idea. I still think that the priority handling
> in the old code is useful.
The one in the db ? Oh my, I wouldn't touch that, it's perfect there.
> It's useful to be able to requeue a package as it
> is
> blocking someone and have it done as soon as a slot is free. I've never felt
> the
> need for more fine-grained than the three levels we have now though (ASAP,
> soon, and
> idle).
Yup. Good point about re-queuing on-demand, but that's already covered by requeue-package --priority no ? ISTM the way you wrote next_job() should give us that since it queries the db for each job... I'm not familiar enough with SQL (nor the requeue_package implementation) but if the query takes the priority into account my implementation will respect it.
When I was mentioning multiple queues/priority I was thinking about the losa proxied queries we may need in the future (including of course requeue-package or any other python script) which is the subject of my next submission.
>
> > If needed, we could add some priority handling in the queue itself, but I
> > think a better plan is to maintain a debian and a lp canaris that will just
> > suspend the execution of imports when one of the sites is down (and kill and
> > requeue the ones in progress at the top of the queue)
>
> I think the canaries are a good idea. I still think that the priority handling
> in the old code is useful.
The one in the db ? Oh my, I wouldn't touch that, it's perfect there.
> It's useful to be able to requeue a package as it
> is
> blocking someone and have it done as soon as a slot is free. I've never felt
> the
> need for more fine-grained than the three levels we have now though (ASAP,
> soon, and
> idle).
Yup. Good point about re-queuing on-demand, but that's already covered by requeue-package --priority no ? ISTM the way you wrote next_job() should give us that since it queries the db for each job... I'm not familiar enough with SQL (nor the requeue_package implementation) but if the query takes the priority into account my implementation will respect it.
When I was mentioning multiple queues/priority I was thinking about the losa proxied queries we may need in the future (including of course requeue-package or any other python script) which is the subject of my next submission.