Open Stack

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.

--ruby

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/liberty/futurist.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/b95dff37/attachment.html>