Open Stack

Hi Sahid,

There is a work-in-progress work to change how concurrency is handled in openstack processes:

"Replace eventlet with ???"
https://review.openstack.org/164035

The latest updates can be found in etherpads from the OpenStack Vancouver Summit:

- https://etherpad.openstack.org/p/liberty-cross-project-managing-concurrency
- https://etherpad.openstack.org/p/YVR-oslo-asyncio

No choice was made at Vancouver. In short, we should continue to investigate the different options (asyncio/trollius, threads, etc.) to get more information to be able to take a decision.

Victor

----- Original Message -----
> From: "Sahid Orentino Ferdjaoui" <sahid.ferdjaoui at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Thursday, May 7, 2015 11:34:51 AM
> Subject: [openstack-dev] [nova][oslo] RPC Asynchronous Communication
> 
> Hi,
> 
> The primary point of this expected discussion around asynchronous
> communication is to optimize performance by reducing latency.
> 
> For instance the design used in Nova and probably other projects let
> able to operate ascynchronous operations from two way.
> 
> 1. When communicate between inter-services
> 2. When communicate to the database
> 
> 1 and 2 are close since they use the same API but I prefer to keep a
> difference here since the high level layer is not the same.
> 
> From Oslo Messaging point of view we currently have two methods to
> invoke an RPC:
> 
>   Cast and Call: The first one is not bloking and will invoke a RPC
>     without to wait any response while the second will block the
>     process and wait for the response.
> 
> The aim is to add new method which will return without to block the
> process an object let's call it "Future" which will provide some basic
> methods to wait and get a response at any time.
> 
> The benefice from Nova will comes on a higher level:
> 
> 1. When communicate between services it will be not necessary to block
>    the process and use this free time to execute some other
>    computations.
> 
>       future = rpcapi.invoke_long_process()
>          ... do something else here ...
>       result = future.get_response()
> 
> 2. We can use the benefice of all of the work previously done with the
>    Conductor and so by updating the framework Objects and Indirection
>    Api we should take advantage of async operations to the database.
> 
>        MyObject = MyClassObject.get_async()
>          ... do something else here ...
>        MyObject.wait()
> 
>        MyObject.foo = "bar"
>        MyObject.save_async()
>          ... do something else here ...
>        MyObject.wait()
> 
> All of this is to illustrate and have to be discussed.
> 
> I guess the first job needs to come from Oslo Messaging so the
> question is to know the feeling here and then from Nova since it will
> be the primary consumer of this feature.
> 
> https://blueprints.launchpad.net/nova/+spec/asynchronous-communication
> 
> Thanks,
> s.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>