On Tue, Mar 19, 2019 at 6:57 PM Sean Mooney <smooney@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