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