Hi Wanyen, Thanks for your input first, I have worked out solution 1 enhanced version, that is very flexible framework from our Ironic part, will not change any data returned by 'ipmitool' command and just format them as JSON string and sent to ceilometer, I think this should be the final solution, I will implement it with python code in our Ironic.
The solution 1 enhanced version is: We run the ipmitool command with 'sdr -v' options, so we get details for each sensor, see the command line and out put as below link: http://paste.openstack.org/show/63267/ Our Ironic will parse these output to JSON string by 'Sensor Type', check the JSON string which will be sent to Ceilometer: http://paste.openstack.org/show/63276/ So from our Ironic part, we will support all sensors which returned from 'ipmitool sdr -v' command, that is flexible framework I think. For this my testing case result, we get a lot of below sensor types, including 'Fan', 'Voltage', 'Temperature' these three common sensors: ['Cable / Interconnect', 'Physical Security', 'System Firmwares', 'Temperature', 'Drive Slot / Bay', 'Battery', 'Unknown (0xC1)', 'Memory', 'Power Supply', 'System Event', 'Module / Board', 'Version Change', 'Fan', 'Voltage', 'Event Logging Disabled', 'Critical Interrupt', 'Watchdog', 'Processor', 'Entity Presence'] However, from Ceilometer part, have to define the 'Meter' data model with these JSON input from our Ironic, so for first version, I think our Ceilometer will support 'Fan', 'Voltage', 'Temperature' first, and will check with Ceilometer team guys how to model/map these ipmi sensor data as ceilometer resource->meter->samples and support more flexibility to accomodate more sensors like our Ironic:) Thanks Haomeng On Sat, Feb 8, 2014 at 6:20 AM, Hsu, Wan-Yen <wan-yen....@hp.com> wrote: >>Haomeng wrote: > > > >>Ok, will implement the bp based on the first solution, thanks. > > > > > > I believe solution 2 is more flexible and it allows hardware to report > additional sensors than solution 1. However, if there is a desire to define > specific sensor categories as proposed by solution 1, then please add an > extra-sensors data structure with key+ value pairs to allow different > hardware to report additional sensors such as average wattage, critical > upper temperature threshold, network, and memory sensors, ...etc. Thanks! > > > > > > Regards, > > Wanyen > > > > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev