RFC: Integrating Aeolus with Heat

Ian Main imain at redhat.com
Thu Aug 30 20:23:35 UTC 2012


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




More information about the aeolus-devel mailing list