[nova][dev] Fixing eventlet monkey patching in Nova

Michael Still mikal at stillhq.com
Tue Mar 19 21:53:13 UTC 2019


On Tue, Mar 19, 2019 at 6:57 PM Sean Mooney <smooney at redhat.com> wrote:

> On Fri, 2019-03-15 at 17:06 -0500, Ben Nemec wrote:
> > On 3/15/19 4:41 PM, Monty Taylor wrote:
>

[snip]


> > > In sdk, there are a few things that need to be done in the background
> > > (when uploading a very large swift object and we're going to split it
> in
> > > to chunks and upload concurrently) In that case we used
> > > concurrent.futures.ThreadPoolExecutor which creates a pool of threads
> > > and allows you to submit jobs into it ... very simiar to the
> > > using-pool-of-workers example above.
> >
> > This is what we did in the oslo.privsep daemon too when we added
> > parallel execution.
>


> yes so on that point i wanted to talk to the oslo team about possibly
> breaking out the core of privsep into oslo concurancy.
>
> for a lot of the concurancy we need in nova we could create a privsep
> deamon context with
> no permisions and simply dispatch the execution of api queries to it but
> that feels a bit
> strainge. i was wondering if there was merrit in either packaging up the
> core of the deamon without
> the actuall privlage seperation logic or provideing a very thin shim over
> the concurrent futures.
> though by the looks of it there is a python2.7 backport already
> https://pypi.org/project/futures/
> i had discounted using concurrent futrues with the ThreadPoolExecutor as i
> had tought it was python 3 only
> but yes it provides a nice api and workflow form this type of concurrent
> or parallel dispatch.
>

Is there a lot of gain to splitting the concurrency out of privsep? The
lack of escalated permissions for a privsep'd function is a very small (one
line IIRC) change.

I haven't looked at the API for parallel privsep to be honest. How does it
handle returning results to callers?


> its a topic i would like to discuss with people at the ptg but i would
> personally be interested in seeing if
> we can 1 remove where resoanable our explict use of eventlets, and second
> explore transitioning to a more explitct
> concurancy model if other were open to it either by  delegating execution
> to an un privalaged privesep deamon or
> something like concurent futures with a thread pool or asyncio event loop
> using
> https://docs.python.org/3/library/asyncio-future.html. my distaste for
> eventlets has mellowed over the last year
> or two as debugers have actully began to understand gevent and greenlets
> but if i had an architetural wand to change
> one thin in the U cycle it would be breaking our eventlet depency and
> moving to a functionality form the standard libary
> instead when we are python 3 only.


One thing I wanted recently was a way to start a thread which ran as a
"sidecar" to nova-compute but didn't share anything with nova-compute apart
from wanting to always be running when nova-compute was. Think the metadata
server or a prometheus metrics exporter. I nearly wrote an implementation
with privsep, but didn't get around to it. I feel like an unprivileged
privsep parallel executor which never returns might be very close to what I
wanted.

I wont be at the PTG, but would like to be kept informed of where you get
to on this.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190320/8baf6495/attachment.html>


More information about the openstack-discuss mailing list