On 22 July 2015 at 08:40, Dmitry Tantsur <[email protected]> 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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
