[openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?

Ruby Loo rlooyahoo at gmail.com
Wed Jul 22 15:43:10 UTC 2015

On 22 July 2015 at 08:40, Dmitry Tantsur <dtantsur at redhat.com> wrote:

> Hi all!
> Currently _spawn_worker in the conductor manager raises
> NoFreeConductorWorker if pool is already full. That's not very user
> friendly (potential source of retries in client) and does not map well on
> common async worker patterns.
> My understanding is that it was done to prevent the conductor thread from
> waiting on pool to become free. If this is true, we no longer need it after
> switch to Futurist, as Futurist maintains internal queue for its green
> executor, just like thread and process executors in stdlib do. Instead of
> blocking the conductor the request will be queued, and a user won't have to
> retry vague (and rare!) HTTP 503 error.
> WDYT about me dropping this exception with move to Futurist?

For a bit more context, Dmitry has a spec to move to Futurist[1]. My
understanding is that Futurist will enqueue tasks if the worker pool is
full. So if we move to Futurist, we will have to drop the exception/change
the existing behaviour, unless we want Futurist to provide something so we
can continue with our existing behaviour.

I am fine with changing the behaviour so that tasks are enqueued and we
don't raise that NoFreeConductorWorker exception. That seems to make sense
to me. But I'm not an operator.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/b95dff37/attachment.html>

More information about the OpenStack-dev mailing list