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" <[email protected] > > <mailto:[email protected]>> 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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
