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_StackResourceDetail.html > 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-ec2-instance.html 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
