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 <fla...@redhat.com> wrote: > On 08/04/15 16:38 +0000, Sandy Walsh wrote: > >> ________________________________________ >> >>> From: Clint Byrum <cl...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
