ipmi sensor naming in ceilometer is not consumer friendly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
High
|
Chris Dent | ||
Ironic |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
ipmi sensor naming in ceilometer is not consumer friendly
I've found the IPMI ceilometer sensor naming structure difficult to deal with from a programmatic perspective if a consumer wants to simply read all the sensors for a given Ironic Node. The IPMI sensor implementation names the ceilometer meters generically as "hardware.
Here is an example output from ceilometer meter-list with the current IPMI sensor naming scheme.
| Name | Type | Unit | Resource ID
| hardware.
| hardware.
I believe a better approach would be to name each ceilometer meter uniquely within a platform and assign each meter a Resource ID equal to the Ironic Node UUID that the meter is associated with. This naming would enable the consumer to query ceilometer for a specific Resource ID which matches the Ironic Node UUID. This query would result in ceilometer returning a single resource containing direct links to all the sensors associated with the resource. Here is an example of a different ceilometer naming scheme which enables ceilometer querying for a specific Ironic Nodes platform information.
| Name | Type | Unit | Resource ID
| hardware.
| hardware.
Changed in ceilometer: | |
assignee: | nobody → Chris Dent (chdent) |
Changed in ironic: | |
status: | New → Confirmed |
Changed in ironic: | |
status: | Confirmed → Won't Fix |
Changed in ceilometer: | |
importance: | Undecided → High |
Changed in ceilometer: | |
milestone: | none → juno-rc2 |
Changed in ceilometer: | |
milestone: | juno-rc2 → 2014.2 |
There was quite a lot of discussion about this when it was created, so I think if we dredge up the respective reviews we should be able to find the rationale and either all will become clear or we can fix it. I can't look now, but will if no one else has gotten around to it by early next week.