Open Stack

Excerpts from Victor Stinner's message of 2014-07-10 05:57:38 -0700:
> Le jeudi 10 juillet 2014, 14:48:04 Yuriy Taraday a écrit :
> > I'm not suggesting that taskflow is useless and asyncio is better (apple vs
> > oranges). I'm saying that using coroutines (asyncio) can improve ways we
> > can use taskflow and provide clearer method of developing these flows.
> > This was mostly response to the "this is impossible with coroutines". I say
> > it is possible and it can even be better.
> 
> It would be nice to modify taskflow to support trollius coroutines. Coroutines 
> supports asynchronous operations and has a better syntax than callbacks.
> 

You mean like this:

https://review.openstack.org/#/c/90881/1/taskflow/engines/action_engine/executor.py

Abandoned, but I think Josh is looking at it. :)

> For Mark's spec, add a new greenio executor to Oslo Messaging: I don't see the 
> direct link to taskflow. taskflow can use Oslo Messaging to call RPC, but I 
> don't see how to use taskflow internally to read a socket (driver), wait for 
> the completion of the callback and then send back the result to the socket 
> (driver).
> 

So oslo and the other low level bits are going to need to be modified
to support coroutines. That is definitely something that will make them
more generally useful anyway. I don't think Josh or I meant to get in
the way of that.

However, having this available is a step toward removing eventlet and
doing the painful work to switch to asyncio. Josh's original email was
in essence a reminder that we should consider a layer on top of asyncio
and eventlet alike, so that the large scale code changes only happen
once.

> I see trollius as a low-level tool to handle simple asynchronous operations, 
> whereas taskflow is more high level to chain correctly more complex operations.
> 

_yes_

> trollius and taskflow must not be exclusive options, they should cooperate, as 
> we plan to support trollius coroutines in Oslo Messaging.
> 

In fact they are emphatically not exclusive. However, considering the
order of adoption should produce a little less chaos for the project.
>