[openstack-dev] [Ironic][Ceilometer] Proposed Change to Sensor meter naming in Ceilometer

Jim Mankovich jmank at hp.com
Thu Oct 16 17:23:42 UTC 2014


I would like to get some feedback on a proposal  to change to the 
current sensor naming implemented in ironic and ceilometer.

I would like to provide vendor specific sensors within the current 
structure for IPMI sensors in ironic and ceilometer, but I have found 
that the current  implementation of sensor meters in ironic and 
ceilometer is IPMI specific (from a meter naming perspective) . This is 
not suitable as it currently stands to support sensor information from a 
provider other than IPMI.    Also, the current Resource ID naming makes 
it difficult for a consumer of sensors to quickly find all the sensors 
for a given Ironic Node ID, so I would like to propose changing the 
Resource ID naming as well.

Currently, sensors sent by ironic to ceilometer get named by ceilometer 
as has "hardware.ipmi.SensorType", and the Resource ID is the Ironic 
Node ID with a post-fix containing the Sensor ID.  For Details 
pertaining to the issue with the Resource ID naming, see 
https://bugs.launchpad.net/ironic/+bug/1377157, "ipmi sensor naming in 
ceilometer is not consumer friendly"

Here is an example of what meters look like for sensors in ceilometer 
with the current implementation:
| Name                        | Type  | Unit | Resource ID
| hardware.ipmi.current       | gauge | W    | 
| hardware.ipmi.temperature   | gauge | C    | 

What I would like to propose is dropping the ipmi string from the name 
altogether and appending the Sensor ID to the name  instead of to the 
Resource ID.   So, transforming the above to the new naming would result 
in the following:
| Name                                     | Type  | Unit | Resource ID
| hardware.current.power_meter_(0x16)      | gauge | W    | 
| hardware.temperature.system_board_(0x15) | gauge | C    | 

This structure would provide the ability for a consumer to do a 
ceilometer resource list using the Ironic Node ID as the Resource ID to 
get all the sensors in a given platform.   The consumer would then then 
iterate over each of the sensors to get the samples it wanted.   In 
order to retain the information as to who provide the sensors, I would 
like to propose that a standard "sensor_provider" field be added to the 
resource_metadata for every sensor where the "sensor_provider" field 
would have a string value indicating the driver that provided the sensor 
information.     This is where the string "ipmi", or a vendor specific 
string would be specified.

I understand that this proposed change is not backward compatible with 
the existing naming, but I don't really see a good solution that would 
retain backward compatibility.

Any/All Feedback will be appreciated,

--- Jim Mankovich | jmank at hp.com (US Mountain Time) ---

More information about the OpenStack-dev mailing list