Open Stack

+1 for using taskflow to implement workflows…  workflow reliability is a
non-trivial problem that is best solved in one place imho

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.

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.

- Min

On Wed, Apr 8, 2015 at 3:14 PM, Joshua Harlow <harlowja at outlook.com> wrote:

> 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.
>>
>
> 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: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150408/14c50b1e/attachment.html>