Open Stack

Uh sorry to nitpick, I think he said “let’s do away with” not “let’s use”
RPC-over-AMQP

On Wed, Apr 8, 2015 at 10:56 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 08/04/15 16:38 +0000, Sandy Walsh wrote:
>
>> ________________________________________
>>
>>> From: Clint Byrum <clint at fewbar.com>
>>> Sent: Wednesday, April 8, 2015 1:15 PM
>>>
>>> There's this:
>>>
>>> https://wiki.openstack.org/wiki/Cue
>>>
>>
>> Hmm, that looks interesting. Will read.
>>
>>  I also want to point out that what I'd actually rather see is that all
>>> of the services provide functionality like this. Users would be served
>>> by having an event stream from Nova telling them when their instances
>>> are active, deleted, stopped, started, error, etc.
>>>
>>> Also, I really liked Sandy's suggestion to use the notifications on the
>>> backend, and then funnel them into something that the user can consume.
>>> The project they have, yagi, for putting them into atom feeds is pretty
>>> interesting. If we could give people a simple API that says "subscribe
>>> to Nova/Cinder/Heat/etc. notifications for instance X, and put them
>>> in an atom feed", that seems like something that would make sense as
>>> an under-the-cloud service that would be relatively low cost and would
>>> ultimately reduce load on API servers.
>>>
>>
>> THIS!
>>
>> Yes. It would be so good to pull apart the state-machine that is Nova and
>> just emit completed actions via notifications. Then, have something like
>> TaskFlow externalize the orchestration. Do away with RPC-over-AMQP.
>>
>
> Sorry for being nitpicky but, saying "RPC-over-AMQP" is way too
> generic. What AMQP version? On top of what technology?
>
> Considering all the issues OPs have with our current broker story, I
> think considering implementing this on top of pure AMQP (which is how
> that phrase reads) would not be good.
>
> If you meant "RPC-over-messaging" then I think you should just keep
> using oslo.nmessaging, which abstracts the problem of picking one
> broker.
>
> Unfortunately, this means users will need to consume this messages
> from the "messaging source" using oslo.messaging as well. I say
> "unfortunately" because I believe the API - or even the protocol - as
> it is exposed through this library - or simply the broker - is not
> something users should deal with. There are services that try to make
> this interaction simpler - yes, Zaqar.
>
> Flavio
>
>
>
>> And, anyone that is interested in the transitions can eavesdrop on the
>> notifications.
>>
>> In our transition from StackTach.v2 to StackTach.v3 in production we
>> simply
>> cloned the notification feeds so the two systems can run in parallel*. No
>> changes to OpenStack, no disruption of service. Later, we'll just kill off
>> the v2 queues.
>>
>> -S
>>
>> * we did this in Yagi, since olso-messaging doesn't support multiple
>> queues
>> from one routing key.
>> ____________________________________________________________
>> ______________
>> 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
>>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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/20150408/b4bd375a/attachment.html>