Open Stack

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
> eventlet.
>
> 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:

http://cdn2.hubspot.net/hub/344789/file-448028030-jpg/images/openstack-arch-grizzly-logical-v2.jpg?t=1414604346389

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.