Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

2014-02-08 Thread Haomeng, Wang
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, this should be the final
solution, 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


Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

2014-02-08 Thread Haomeng, Wang
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


Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

2014-01-29 Thread Gordon Chung
 Meter Names:
 fanspeed, fanspeed.min, fanspeed.max, fanspeed.status
 voltage, voltage.min, voltage.max, voltage.status
 temperature, temperature.min, temperature.max, 
temperature.status
 
 'FAN 1': {
 'current_value': '4652',
 'min_value': '4200',
 'max_value': '4693',
 'status': 'ok'
 }
 'FAN 2': {
 'current_value': '4322',
 'min_value': '4210',
 'max_value': '4593',
 'status': 'ok'
 },
 'voltage': {
 'Vcore': {
 'current_value': '0.81',
 'min_value': '0.80',
 'max_value': '0.85',
 'status': 'ok'
 },
 '3.3VCC': {
 'current_value': '3.36',
 'min_value': '3.20',
 'max_value': '3.56',
 'status': 'ok'
 },
 ...
 }
 }

are FAN 1, FAN 2, Vcore, etc... variable names or values that would 
consistently show up? if the former, would it make sense to have the 
meters be similar to fanspeed:trait where trait is FAN1, FAN2, etc...? 
if the meter is just fanspeed, what would the volume be? FAN 1's 
current_value?

cheers,

gordon chung
openstack, ibm software standards
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

2014-01-29 Thread Devananda van der Veen
On Wed, Jan 29, 2014 at 7:22 AM, Gordon Chung chu...@ca.ibm.com wrote:

  Meter Names:
  fanspeed, fanspeed.min, fanspeed.max, fanspeed.status
  voltage, voltage.min, voltage.max, voltage.status
  temperature, temperature.min, temperature.max, temperature.status
 
  'FAN 1': {
  'current_value': '4652',
  'min_value': '4200',
  'max_value': '4693',
  'status': 'ok'
  }
  'FAN 2': {
  'current_value': '4322',
  'min_value': '4210',
  'max_value': '4593',
  'status': 'ok'
  },
  'voltage': {
  'Vcore': {
  'current_value': '0.81',
  'min_value': '0.80',
  'max_value': '0.85',
  'status': 'ok'
  },
  '3.3VCC': {
  'current_value': '3.36',
  'min_value': '3.20',
  'max_value': '3.56',
  'status': 'ok'
  },
  ...
  }
  }


 are FAN 1, FAN 2, Vcore, etc... variable names or values that would
 consistently show up? if the former, would it make sense to have the meters
 be similar to fanspeed:trait where trait is FAN1, FAN2, etc...? if the
 meter is just fanspeed, what would the volume be? FAN 1's current_value?


Different hardware will expose different number of each of these things. In
Haomeng's first proposal, all hardware would expose a fanspeed and a
voltage category, but with a variable number of meters in each category.
In the second proposal, it looks like there are no categories and hardware
exposes a variable number of meters whose names adhere to some consistent
structure (eg, FAN ? and V???).

It looks to me like the question is whether or not to use categories to
group similar meters.

-Devananda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev