Re: [openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?
On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur 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? I kind of like this, but with my operator hat on this is a bit scary. Does Futurist just queue all requests indefinitely? Is it configurable? Am I able to get any insight into the current state of that queue? Just indefinitely queueing up everything seems like it could end with a system that's backlogged to death, with no way to determine if that's actually the problem or not. // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?
On 22 July 2015 at 08:40, Dmitry Tantsur dtant...@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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?
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? Dmitry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
