On 03/05/2013 11:55 AM, Steven Hardy wrote:
On Wed, Feb 27, 2013 at 06:47:16PM +0100, Tomas Sedovic wrote:
> Dear Aeolus community,
> I've sent the first pull request integrating Heat with Conductor.
> Please have a look at the changes here:
> The pull request contains some observations, notes and rambling that
> should start a discussion on things I missed, did incorrectly, etc.
> For your convenience, I'm pasting it here as well:
> This is the first step towards full Heat integration. This routes
> deployment launching and querying for status to Heat. Launch-time
> parameters should just work, ditto for deleting the instances.
> This is mostly to give you guys a direction where I think this
> should go and to get comments and feedback. I don't think it's wise
> to merge it just yet -- we need to test it more, clean up the code,
> find the subtle things this breaks, etc.
> There are also a few issues that need fixing:
> * Heat's API supports atomic launch (i.e. rollback) but as far as I
> know, it's not been implemented yet
I implemented this (for stack create and update) recently, it landed for the
Grizzly-3 development milestone:
Note this feature is disabled by default in current heat master (it wasn't
for g3) because we don't yet have persistent stack events:
You can enable it with the heat-cfn/heat-boto/heat tools with the
--enable-rollback option on stack create
Thanks, I didn't know that. I'll check it out.
Note that this rollback flag is defined at stack creation time, and
currently cannot be changed during the lifetime of the stack (same as AWS,
but maybe we should allow specifying it explicitly on StackUpdate)
That's perfectly fine for our use case, actually.
> * There's a bug in Heat that means the actual instance status isn't
> reported back correctly. If you launch a deployment and stop the
> instances out of band, Heat will show them as running.
Is there a bug report for this?
Also I'm not sure what you mean by running - we track resource creation
status, not instantaneous state/health of any instance/resource - that must
be done via CloudWatch alarms, e.g like the HA/Autoscaling templates.
So when your Instance resource goes CREATE_COMPLETE, after that we don't
care if it's running or not - if the user thinks instances may need
restarting for some reason, they need to make use of WaitConditions, the HA
features and CloudWatch alarms.
I see, I may have misunderstood what that field means, then.
I was talking about reporting the ACTIVE/STOPPED/ERROR OpenStack state
to monitor if the instance goes down, etc.
I thought this would be passed via the `resource_status` field. But it
may very well make more sense to get to this via HA/CloudWatch
capabilities as you suggest. I'll look into it more.
It would still be useful to report these state changes in the events I
think. Is that being done already / would Heat be interested in having that?