Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer
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
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
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
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
[openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer
Hi,
I am working on this ironic bp -
https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer,
worked out solutions as below, can you help to review, welcome your
comments:
We will call ipmi command/api to get sensor data(sensor name, sensor
current value, min/max value, status etc) and try to sent to
ceilometer collector via notification bus(call rpc_notifier.notify()
api to send the ipmi data message) with ironic periodic task, I have
two proposed ironic-ceilometer integration solutions about the data to
be sent to ceilometer:
Solution 1 - sent the ipmi data to ceilometer by ipmi sensor category
in specific, the meter names vary clear for ceilometer, that is
pre-defined already:
Common field:
timestamp
publisher_id
message_id
resource-id #the ironic node-uuid
Category:
FanSpeed
Voltage
Temperature
Meter Names:
fanspeed, fanspeed.min, fanspeed.max, fanspeed.status
voltage, voltage.min, voltage.max, voltage.status
temperature, temperature.min, temperature.max, temperature.status
An message example with one ipmi node sensor data:
message = {
'event_type': 'ipmidata',
'timestamp': '2013-12-1706: 12: 11.554607',
'user_id': 'admin',
'publisher_id': 'ipmidata-os26-control01.localdomain',
'message_id:' '3eca2746-9d81-42cd-b0b3-4bdec52e109x',
'tenant_id: 'c1921aa2216846919269a17978408476',
'instance_uuid: '96e11f69-f12a-485e-abfa-526cd04169c4' # nova
instance uuid
'id': '1329998e8183419794507cd6f0cc121a' # node's uuid
'payload': {
'fanspeed': {
'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'
},
...
}
}
Solution 2- sent the ipmi data to ceilometer on the common sensor
meter level, we have one 'sensor' as common meter, so all the sensor
data will have more detail level to define the sensor name and
attributes - current/min/max/status values:
Common field:
timestamp
publisher_id
message_id
Common sensor meter name:
sensor
An message example with one ipmi node sensor data:
message = {
'event_type': 'ipmidata',
'timestamp': '2013-12-1706: 12: 11.554607',
'user_id': 'admin',
'publisher_id': 'ipmidata-os26-control01.localdomain',
'message_id:' '3eca2746-9d81-42cd-b0b3-4bdec52e109x',
'tenant_id: 'c1921aa2216846919269a17978408476',
'instance_uuid: '96e11f69-f12a-485e-abfa-526cd04169c4' # nova
instance uuid
'id': '1329998e8183419794507cd6f0cc121a' # node's uuid
'payload': {
'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'
},
'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'
},
...
}
}
And we have existing patch in ceilometer 'Add ipmi inspector' -
https://review.openstack.org/#/c/51828, it is Abandoned, but I think
we should have same patch/bp in ceilometer to handle the ipmi data
message sent out from ironic. Once the solution is confirmed and
finalized, I will work with ceilometer team to do the testing to
verify if our solution working or not.
Thanks
Haomeng
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
