Need to include state of an instance in resource metadata

Registered by Pradeep Kilambi on 2014-03-31

Currently there is no way to determine the state of an instance whether the instance is Active, shutoff, terminated etc

Nova already raises events when the instance state changes. Its needs to be captured and included as part of the metadata. Will submit a patch soon.

Blueprint information

Status:
Complete
Approver:
Eoghan Glynn
Priority:
Medium
Drafter:
Pradeep Kilambi
Direction:
Approved
Assignee:
Pradeep Kilambi
Definition:
Approved
Series goal:
Accepted for juno
Implementation:
Implemented
Milestone target:
milestone icon 2014.2
Started by
Pradeep Kilambi on 2014-03-31
Completed by
Pradeep Kilambi on 2014-04-08

Related branches

Sprints

Whiteboard

is this different from https://blueprints.launchpad.net/ceilometer/+spec/state-meter?
--gordc

interesting, looks related. I was intending to include the state as part of the resource metadata for the instance itself. Looks like ceilometer already polled the existence of an instance, so we could capture the VM state at that point. Dint think a new pollster was needed. --pkilambi

ok. well if the bp are trying to accomplish same goal we should try discussing proper implementation on the older one. if they're similar but different i'm ok to keep this open. just wanted to bring to your attention there's a similar bp that exists.
-- gordc

Thanks. Agreed, to me it felt like the state would fit better in a resource metadata and less intensive. That would eliminate the need to have a lookup hash like he has and keep that outside of ceilometer, But I'm ok if we indeed need a separate pollster for this. I'll comment in the review.

This would fulfil my requirements that I was addressing with my state-metric. What I think might be more worthwhile though is making a new patch/blueprint for making all the instance metadata across notifications and pollsters consistent. Consistent metadata could also remove the need for: https://blueprints.launchpad.net/ceilometer/+spec/flavor-id-metric although that metric might be useful to get rid of the need for instance:<type>.
The other point though is that the state metric could also double as an existence metric (which is currently just a metadata store), which has more innate value to it at a glance than the instance metric.
Partly off topic: What confuses me though is if we're worried about overhead, why does every entry have attached metadata, which is effectively duplicated across all metrics for a given resource? Why isn't there a single metadata log per resource? It seems we're using the instance metric as that, but all the other metrics have the same metadata.
--adriant

Gerrit topic: https://review.openstack.org/#q,topic:bp/ceilometer-instance-state-measurement,n,z

Addressed by: https://review.openstack.org/84438
    Include instance state in metadata

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.