Open Stack

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" <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 :)

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.