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
