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