Open Stack

Excerpts from Flavio Percoco's message of 2014-09-19 02:37:08 -0700:
> On 09/18/2014 11:51 AM, Angus Salkeld wrote:
> > 
> > On 18/09/2014 7:11 PM, "Flavio Percoco" <flavio at redhat.com
> > <mailto:flavio at redhat.com>> wrote:
> >>
> >> Greetings,
> >>
> >> If I recall correctly, Heat was planning to adopt Zaqar regardless of
> >> the result of the graduation attempt (please correct me if I'm wrong).
> >> Based on this assumption, I'd like to start working on a plan forward to
> >> make this integration happen.
> >>
> >> So far, these are the use cases I've collected from past discussions:
> >>
> >> * Notify  heat user before an action is taken, and after - Heat may want
> >> to wait  for a response before proceeding - notifications not
> >> necessarily needed  and signed read-only queues might help, but not
> >> necessary
> >>     * For integrating with user's tools
> >>         * Monitoring
> >>         * Control surface
> >>         * Config management tools
> >>     * Does not require notifications and/or read-only/signed queue
> > endpoints
> >>         *[These may be helpful, but were not brought up in the discussion]
> >>     * Subscribe to an aggregate feed of interesting events from other
> >> open-stack components (such as Nova)
> >>         * Heat is often deployed in a different place than other
> >> components and doesn't have access to the AMQP bus
> >>         * Large  deployments consist of multiple AMQP brokers, and there
> >> doesn't seem to  be a nice way to aggregate all those events [need to
> >> confirm]
> >>     * Push metadata updates to os-collect-config agent running in
> >> servers, instead of having them poll Heat
> >>
> >>
> >> Few questions that I think we should start from:
> >>
> >> - Does the above list cover Heat's needs?
> >> - Which of the use cases listed above should be addressed first?
> > 
> > IMHO it would be great to simply replace the event store we have
> > currently, so that the user can get a stream of progress messages during
> > the deployment.
> 
> Could you point me to the right piece of code and/or documentation so I
> can understand better what it does and where do you want it to go?

https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/event.py

We currently use db_api to store these in the database, which is costly.

Would be much better if we could just shove them into a message queue for
the user. It is problematic though, as we have event-list and event-show
in the Heat API which basically work the same as the things we've been
wanting removed from Zaqar's API: access by ID and pagination. ;)

I think ideally we'd deprecate those or populate them with nothing if
the user has opted to use messaging instead.