On Tue, Mar 05, 2013 at 05:33:28PM +0100, Tomas Sedovic wrote: <snip>
- 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.
Yep, we can't pass this information via the heat (orchestration) API, since we can only express a specific subset of resource states related to the resource lifecycle in the ResourceStatus field:
http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_StackRe...
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?
Not being done already, I think in openstack the expectation would be for these state changes to be monitored via Ceilometer, not Heat, although I agree exposing this information would be useful.
Looking at the way AWS does it, they provide a "Monitoring" property to the AWS::EC2::Instance resource type, which heat doesn't currently implement:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties...
It seems like the closest approximation to this would be to set up a nova notification for state changes (not sure on the current state of this..)
http://docs.openstack.org/developer/nova/api/nova.notifications.html
Then I guess we could have a callback to heat which created heat resource events based on state changes reported by nova - but if we did this, I think we'd need to be careful not to overlap in any way with the monitoring capabilities provided (or planned to be provided) by Ceilometer.
I think for the Aeolus use-case we need to give some consideration to what happens when Ceilometer becomes the primary source of alarms for Heat - we are not planning to maintain our internal Cloudwatch metric/alarm infrastructure indefinitely, so we may need to come up with a separate solution for Aeolus to use.
Steve