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
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
Having a clear programming model around Messaging calls that scales
should not compromise system integrity, it should complement it.
OpenStack-dev mailing list