Sandy Walsh wrote:
________________________________________
From: Clint Byrum<[email protected]>
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.
Sounds good to me ;)
http://docs.openstack.org/developer/taskflow/notifications.html were
designed for this purpose; some of the implementations at:
http://docs.openstack.org/developer/taskflow/notifications.html#implementations
I know that http://www.rackspace.com/cloud/big-data/ is using one of
these (among others) and using it to do various tracking of
workflows/tasks, and such and gathering the information at whatever
level is desired.
The neat thing is that it allows for post-workflow addition of listeners
so if at some future point you want to know the timing of your workflow,
well u can just plug another listener in that gathers this information
(for example
http://docs.openstack.org/developer/taskflow/notifications.html#taskflow.listeners.timing.EventTimeListener)...
-Josh
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
