Open Stack

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