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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
