<div dir="ltr"><div dir="ltr">On Tue, Mar 19, 2019 at 6:57 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-03-15 at 17:06 -0500, Ben Nemec wrote:<br>
> On 3/15/19 4:41 PM, Monty Taylor wrote:<br></blockquote><div><br></div><div>[snip]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > In sdk, there are a few things that need to be done in the background <br>
> > (when uploading a very large swift object and we're going to split it in <br>
> > to chunks and upload concurrently) In that case we used <br>
> > concurrent.futures.ThreadPoolExecutor which creates a pool of threads <br>
> > and allows you to submit jobs into it ... very simiar to the <br>
> > using-pool-of-workers example above.<br>
> <br>
> This is what we did in the oslo.privsep daemon too when we added <br>
> parallel execution.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
yes so on that point i wanted to talk to the oslo team about possibly<br>
breaking out the core of privsep into oslo concurancy.<br>
<br>
for a lot of the concurancy we need in nova we could create a privsep deamon context with<br>
no permisions and simply dispatch the execution of api queries to it but that feels a bit<br>
strainge. i was wondering if there was merrit in either packaging up the core of the deamon without<br>
the actuall privlage seperation logic or provideing a very thin shim over the concurrent futures.<br>
though by the looks of it there is a python2.7 backport already <a href="https://pypi.org/project/futures/" rel="noreferrer" target="_blank">https://pypi.org/project/futures/</a><br>
i had discounted using concurrent futrues with the ThreadPoolExecutor as i had tought it was python 3 only<br>
but yes it provides a nice api and workflow form this type of concurrent or parallel dispatch.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>I haven't looked at the API for parallel privsep to be honest. How does it handle returning results to callers?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
its a topic i would like to discuss with people at the ptg but i would personally be interested in seeing if<br>
we can 1 remove where resoanable our explict use of eventlets, and second explore transitioning to a more explitct<br>
concurancy model if other were open to it either by  delegating execution to an un privalaged privesep deamon or<br>
something like concurent futures with a thread pool or asyncio event loop using <br>
<a href="https://docs.python.org/3/library/asyncio-future.html" rel="noreferrer" target="_blank">https://docs.python.org/3/library/asyncio-future.html</a>. my distaste for eventlets has mellowed over the last year<br>
or two as debugers have actully began to understand gevent and greenlets but if i had an architetural wand to change<br>
one thin in the U cycle it would be breaking our eventlet depency and moving to a functionality form the standard libary<br>
instead when we are python 3 only.</blockquote><div><br></div><div>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.<br></div><div><br></div><div>I wont be at the PTG, but would like to be kept informed of where you get to on this.</div><div><br></div><div>Michael</div></div></div>