<div dir="ltr">Hello.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 5:38 PM, victor stinner <span dir="ltr"><<a href="mailto:victor.stinner@enovance.com" target="_blank">victor.stinner@enovance.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to replace eventlet with asyncio in OpenStack for the asynchronous programming. The new asyncio module has a better design and is less "magical". It is now part of python 3.4 arguably becoming the de-facto standard for asynchronous programming in Python world.<br>

</blockquote><div><br></div><div>I think that before doing this big move to yet another asynchronous framework we should ask the main question: Do we need it? Why do we actually need async framework inside our code?</div>

<div>There most likely is some historical reason why (almost) every OpenStack project runs every its process with eventlet hub, but I think we should reconsider this now when it's clear that we can't go forward with eventlet (because of py3k mostly) and we're going to put considerable amount of resources into switching to another async framework.</div>

<div><br></div><div>Let's take Nova for example.</div><div><br></div><div>There are two kinds of processes there: nova-api and others.</div><div><br></div><div>- nova-api process forks to a number of workers listening on one socket and running a single greenthread for each incoming request;</div>

<div>- other services (workers) constantly poll some queue and spawn a greenthread for each incoming request.</div><div><br></div><div>Both kinds to basically the same job: receive a request, run a handler in a greenthread. Sounds very much like a job for some application server that does just that and does it good.</div>

<div>If we remove all dependencies from eventlet or any other async framework, we would not only be able to write Python code without need to keep in mind that we're running in some reactor (that's why eventlet was chosen over Twisted IIRC), but we can also forget about all these frameworks altogether.</div>

<div><br></div><div>I suggest approach like this:</div><div>- for API services use dead-simple threaded WSGI server (we have one in the stdlib by the way - in wsgiref);</div><div>- for workers use simple threading-based oslo.messaging loop (it's on its way).</div>

<div><br></div><div>Of course, it won't be production-ready. Dumb threaded approach won't scale but we don't have to write our own scaling here. There are other tools around to do this: Apache httpd, Gunicorn, uWSGI, etc. And they will work better in production environment than any code we write because they are proven with time and on huge scales.</div>

<div><br></div><div>So once we want to go to production, we can deploy things this way for example:</div><div>- API services can be deployed within Apache server or any other HTTP server with WSGI backend (Keystone already can be deployed within Apache);</div>

<div>- workers can be deployed in any non-HTTP application server, uWSGI is a great example of one that can work in this mode.</div><div><br></div><div>With this approach we can leave the burden of process management, load balancing, etc. to the services that are really good at it.</div>

<div><br></div><div>What do you think about this?</div></div><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>