Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150408/b76ba40f/attachment.pgp>