[openstack-dev] [Heat][Zaqar] Integration plan moving forward

Zane Bitter zbitter at redhat.com
Fri Sep 19 22:42:17 UTC 2014


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" <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.

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.



More information about the OpenStack-dev mailing list