On 08/04/15 15:35 -0700, Min Pae wrote:
Uh sorry to nitpick, I think he said “let’s do away with” not “let’s use” RPC-over-AMQP
How is that different? I honestly don't see the difference but I'm surre I'm missing something in my translation.
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
-- @flaper87 Flavio Percoco
pgpCO0u00zDmL.pgp
Description: PGP signature
__________________________________________________________________________ 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
