[openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?
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. 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...
More information about the OpenStack-dev