Open Stack

Hi,

> I also just put up another proposal to consider:
> https://review.openstack.org/#/c/156711/
> """Sew over eventlet + patching with threads"""

My asyncio spec is unclear about WSGI, I just wrote

"The spec doesn't change OpenStack components running WSGI servers
like nova-api. The specific problem of using asyncio with WSGI will
need a separated spec."

Joshua's threads spec proposes:

"I would prefer to let applications such as apache or others handle
the request as they see fit and just make sure that our applications
provide wsgi entrypoints that are stateless and can be horizontally
scaled as needed (aka remove all eventlet and thread ... semantics
and usage from these entrypoints entirely)."

Keystone wants to do the same:
https://review.openstack.org/#/c/157495/
"Deprecate Eventlet Deployment in favor of wsgi containers

This deprecates Eventlet support in documentation and on invocation
of keystone-all."

I agree: we don't need concurrency in the code handling a single HTTP request: use blocking functions calls. You should rely on highly efficient HTTP servers like Apache, nginx, werkzeug, etc. There is a lot of choice, just pick your favorite server ;-) Each HTTP request is handled in a thread. You can use N processes and each process running M threads. It's a common architecture design which is efficient.

For database accesses, just use regular blocking calls (no need to modify SQLAchemy). According to Mike Bayer's benchmark (*), it's even the fastest method if your code is database intensive. You may share a pool of database connections between the threads, but a connection should only be used by a single thread.

(*) http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/

I don't think that we need a spec if everybody already agree on the design :-)

Victor