RFC: Integrating Aeolus with Heat

Jan Provazník jprovazn at redhat.com
Mon Sep 3 10:44:05 UTC 2012


On 08/30/2012 10:23 PM, Ian Main wrote:
> On Thu, Aug 30, 2012 at 09:21:37AM +0200, Jan Provaznik wrote:
>> On 08/29/2012 09:55 PM, Ian Main wrote:
>>> On Mon, Aug 27, 2012 at 02:47:42PM +0200, Jan Provaznik wrote:
>>>> On 08/21/2012 06:15 PM, Tomas Sedovic wrote:
>>>>> Hey Folks,
>>>>>
>>>
>>> [snip]
>>>
>>>>> ### Querying Heat data from Conductor ###
>>>>>
>>>>> Heat doesn't support any callbacks. When Conductor wants to know details
>>>>> about the stack it launched, it will use the CloudFormation API to query
>>>>> the data.
>>>>>
>>>>> For the proof of concept stage, we will just issue the query to Heat
>>>>> upon every relevant UI action: e.g. `ListStacks` when showing
>>>>> deployables in the UI, `DescribeStackResource` when shoving a details of
>>>>> a single deployable, `DescribeStackEvents` to get deployable events, etc.
>>>>>
>>>>
>>>> This is OK for POC, but it would be really nice to have callback
>>>> support for real integration.
>>>>
>>>> nit: you probably meant 'deployment' instead of 'deployable' in the
>>>> paragraph above.
>>>
>>> I am curious as to why you think it is necessary to use callbacks and
>>> mirror the data held in heat within aeolus?
>>>
>>>      Ian
>>>
>>
>> Conductor needs to know if/when a deployment or single instance
>> changed its state (is this what you mean by mirroring data?). W/o
>> notification support on Heat side, Conductor would have to poll Heat
>> which is painful (dbomatic-like service presence on conductor side)
>> and not very effective.
>
> I agree dbomatic type service is error prone.  However mirroring data
> from one service to another is a very difficult problem to solve well
> and have it be reliable.
>
> Is this required for some sort of reporting?  If it is just for the

Yes, reporting and keeping history logs about instances is part of 
Conductor. Conductor also uses this information when choosing a provider 
when launching an instance and also for quota checking.

> user to view the states then that can be done on an as-needed basis by
> contacting heat.  Even reporting is part of the AWS cloudformations API
> and events for stacks are supposed to be kept around for something like
> 90 days (iirc).
>
> Personally I very much question the need to mirror the data heat retains
> into Aeolus as these kinds of things are very error prone and difficult.
> Unless there is some kind of special need for reporting etc. the data
> could just as easily be queried directly.
>
>      Ian
>

Besides the needs listed above, I'm afraid there might be performance 
issues with querying Heat directly per each user request.

Jan



More information about the aeolus-devel mailing list