Hi Tomas,
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:
https://github.com/aeolusproject/conductor/pull/424
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:
https://blueprints.launchpad.net/heat/+spec/stack-rollback https://blueprints.launchpad.net/heat/+spec/update-rollback
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:
https://bugs.launchpad.net/heat/+bug/1131303 https://blueprints.launchpad.net/heat/+spec/event-persistence
You can enable it with the heat-cfn/heat-boto/heat tools with the --enable-rollback option on stack create
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)
- 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.
Steve