On 09/19/2014 03:42 PM, Zane Bitter wrote: > On 19/09/14 14:34, Clint Byrum wrote: >> 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. > > At least initially we'll need to do both, since not everybody has Zaqar. > If we can not have events at all in v2 of the API that would be > fantastic though :)
Yeah - don't forget the folks who are deploying heat in standalone mode who may not have (or want) an additional event stream service thing. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
