<div dir="ltr">+1 for using taskflow to implement workflows…  workflow reliability is a non-trivial problem that is best solved in one place imho<div><br></div><div>I have doubts as to whether AMQP is the right protocol for notifications.  Web service interfaces, thus far, being the “standard” interface for interacting with Openstack, it would seem like the best thing to do is to stay with a web centric protocol like Atom or RSS for delivering notifications.</div><div><br></div><div>Also, as to where the notification should be served out of, whether it’s provided by the service itself vs a common shared service (like Ceilometer or Zaqar), I feel like the service APIs are management interfaces and should not be for event notifications, since the scaling requirements on a management interface (which might have to support complex workflows) and a notification interface (which would be simple in logic but very high in volume) would be different.  Does that mean each service should provide a separate web stack for serving notifications?  I think there’s a benefit to being able to go to a single place for notifications, and if I’m an operator I’d rather have a fewer things to maintain, so a centralized notification service seems like the better choice.</div><div><br></div><div>- Min</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 3:14 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Sandy Walsh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>__________<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Clint Byrum<<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>><br>
Sent: Wednesday, April 8, 2015 1:15 PM<br>
<br>
There's this:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Cue" target="_blank">https://wiki.openstack.org/<u></u>wiki/Cue</a><br>
</blockquote>
<br>
Hmm, that looks interesting. Will read.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also want to point out that what I'd actually rather see is that all<br>
of the services provide functionality like this. Users would be served<br>
by having an event stream from Nova telling them when their instances<br>
are active, deleted, stopped, started, error, etc.<br>
<br>
Also, I really liked Sandy's suggestion to use the notifications on the<br>
backend, and then funnel them into something that the user can consume.<br>
The project they have, yagi, for putting them into atom feeds is pretty<br>
interesting. If we could give people a simple API that says "subscribe<br>
to Nova/Cinder/Heat/etc. notifications for instance X, and put them<br>
in an atom feed", that seems like something that would make sense as<br>
an under-the-cloud service that would be relatively low cost and would<br>
ultimately reduce load on API servers.<br>
</blockquote>
<br>
THIS!<br>
<br>
Yes. It would be so good to pull apart the state-machine that is Nova and<br>
just emit completed actions via notifications. Then, have something like<br>
TaskFlow externalize the orchestration. Do away with RPC-over-AMQP.<br>
</blockquote>
<br></span>
Sounds good to me ;)<br>
<br>
<a href="http://docs.openstack.org/developer/taskflow/notifications.html" target="_blank">http://docs.openstack.org/<u></u>developer/taskflow/<u></u>notifications.html</a> were designed for this purpose; some of the implementations at:<br>
<br>
<a href="http://docs.openstack.org/developer/taskflow/notifications.html#implementations" target="_blank">http://docs.openstack.org/<u></u>developer/taskflow/<u></u>notifications.html#<u></u>implementations</a><br>
<br>
I know that <a href="http://www.rackspace.com/cloud/big-data/" target="_blank">http://www.rackspace.com/<u></u>cloud/big-data/</a> 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.<br>
<br>
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 <a href="http://docs.openstack.org/developer/taskflow/notifications.html#taskflow.listeners.timing.EventTimeListener)." target="_blank">http://docs.openstack.org/<u></u>developer/taskflow/<u></u>notifications.html#taskflow.<u></u>listeners.timing.<u></u>EventTimeListener).</a>..<br>
<br>
-Josh<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And, anyone that is interested in the transitions can eavesdrop on the<br>
notifications.<br>
<br>
In our transition from StackTach.v2 to StackTach.v3 in production we simply<br>
cloned the notification feeds so the two systems can run in parallel*. No<br>
changes to OpenStack, no disruption of service. Later, we'll just kill off<br>
the v2 queues.<br>
<br>
-S<br>
<br>
* we did this in Yagi, since olso-messaging doesn't support multiple queues<br>
from one routing key.<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>