On 11/23/2014 06:13 PM, Robert Collins wrote:
On WSGI - if we're in an asyncio world, I don't think WSGI has any
relevance today - it has no async programming model. While is has
incremental apis and supports generators, thats not close enough to
the same thing: so we're going to have to port our glue code to
whatever container we end up with. As you know I'm pushing on a revamp
of WSGI right now, and I'd be delighted to help put together a
WSGI-for-asyncio PEP, but I think its best thought of as a separate
thing to WSGI per se. It might be a profile of WSGI2 though, since
there is quite some interest in truely async models.

However I've a bigger picture concern. OpenStack only relatively
recently switched away from an explicit async model (Twisted) to

I'm worried that this is switching back to something we switched away
from (in that Twisted and asyncio have much more in common than either
Twisted and eventlet w/magic, or asyncio and eventlet w/magic).

We don't need to use this for WSGI applications. We need to use this for the non-api, message driven portions. WSGI applications should not be accepting events/messages. They already have a messaging model with HTTP, and we should use that and only that.

We need to get the Web based services off Eventlet and into Web servers where we can make use of Native code for security reasons.

Referencing the fine, if somewhat overused model from Ken Pepple:


Only the Nova and Quantum (now Neutron, yes it is dated) API server shows an arrow coming out of the message queue. Those arrows should be broken. If we need to write a micro-service as a listener that receives an event off the queue and makes an HTTP call to an API server, let us do that.

For pieces such as the Nova compute that talk almost exclusively on the Queue, we should work to remove Monkey patching and use a clear programming model. If we can do that within the context of Eventlet, great. If we need to replace Eventlet with a different model, it will be painful, but should be done. What is most important is that we avoid doing hacks like we've had to do with calls to Memcached and monkeypatching threading.

Having a clear programming model around Messaging calls that scales should not compromise system integrity, it should complement it.

OpenStack-dev mailing list

Reply via email to