Hope this helps:
'Let's do away with' == 'remove it/no longer use it'
vs 'let's use RPC-over-AMQP' which means continue using it/use it more.
Flavio Percoco wrote:
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
__________________________________________________________________________
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
