On Fri, 17 Oct 2014, Jim Mankovich wrote:
See answers inline. I don't have any concrete answers as to how to deal with some of questions you brought up, but I do have some more detail that may be useful to further the discussion.
That seems like progress to me.
Personally, I would like to see the _(0x##) removed form the Sensor ID string (by the ipmitool driver) before it returns sensors to the Ironic conductor. I just don't see any value in this extra info. This 0x## addition only helps if a vendor used the exact same Sensor ID string for multiple sensors of the same sensor type. i.e. Multiple sensors of type "Temperature", each with the exact same Sensor ID string of "CPU" instead of giving each Sensor ID string a unique name like "CPU 1 ", " CPU 2",...
Is it worthwhile metadata to save, even if it isn't in the meter name?
In a heterogeneous platform environment, the Sensor ID string is likely going to be different per vendor, so your question "If temperate...on any system board...on any hardware, notify the authorities" is going to be tough because each vendor may name their "system board" differently. But, I bet that vendors use similar strings, so worst case, your alarm creation could require 1 alarm definition per vendor.
The alarm defintion I want to make is (as an operator not as a dev): "My puter's too hot, haaaalp!" Making that easy is the proper (to me) endpoint of a conversation about how to name meters.
I see generic naming as somewhat problematic. If you lump all the temperature sensors for a platform under hardware.temperature the consumer will always need to query for a specific temperature sensor that it is interested in, like "system board". The notion of having different samples from multiple sensors under a single generic name seems harder to deal with to me. If you have multiple temperature samples under the same generic meter name, how do you figure out what all the possible temperature samples actual exist?
I'm not suggestion all temperate sensors under one name ("hardware.temperature"), but all sensors which identify as the same thing (e.g. "hardware.temperature.system_board") under the same name. I'm not very informed about IMPI or hardware sensors, but I do have some experiencing in using names and identifiers (don't we all!) and I find that far too often we name things based on where they come from rather than how we wish to address them after genesis. Throughout ceilometer I think there are tons of opportunities to improve the naming of meters and as a result improve the UI for people who want to do things with the data. So from my perspective, with regard to naming IPMI (and other hardware sensor) related samples, I think we need to make a better list of the use cases which the samples need to satisfy and use that to drive a naming scheme. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev