Open Stack

On Thu, May 21, 2015 at 8:13 AM, Sahid Orentino Ferdjaoui <
sahid.ferdjaoui at redhat.com> wrote:

> On Fri, May 08, 2015 at 09:13:59AM -0400, Doug Hellmann wrote:
> > Excerpts from Joe Gordon's message of 2015-05-07 17:43:06 -0700:
> > > On May 7, 2015 2:37 AM, "Sahid Orentino Ferdjaoui" <
> > > sahid.ferdjaoui at redhat.com> wrote:
> > > >
> > > > 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.
> > >
> > > Isn't this what the use of green threads (and eventlet) is supposed to
> > > solve. Assuming my understanding is correct, and we can fix any issues
> > > without adding async oslo.messaging, then adding yet another async
> pattern
> > > seems like a bad thing.
>
> The aim is to be not library specific and avoid to add different and
> custom patterns on the base code each time we want something not
> blocking.
> We can let the well experimented community working in olso messaging
> to maintain that part and as Doug said oslo can use different
> "executors" so we can avoid the requirement of a specific library.
>

I see no problem with nova depending on a specific async library. I am not
keen on adding yet another column to our support matrix.


>
> > Yes, this is what the various executors in the messaging library do,
> > including the eventlet-based executor we use by default.
> >
> > Where are you seeing nova block on RPC calls?
>
> In Nova we use the indirection api to make call to the database by the
> conductor through RPCs.
> By the solution presented we can create async operations to read and
> write from the database.
>
> Olekssi asks me to give an example I will reply to him.
>
> s.
> > Doug
> >
> >
> __________________________________________________________________________
> > 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150522/a53c01fb/attachment.html>