Open Stack

On 10/20/2014 6:53 AM, Chris Dent wrote:
> 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?
Removing the _(0x##) from the sensor name and keeping the _(0x##) in the
metadata Sensor ID string works for me.
>
>> 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 understand your operator example, but it could be the case every different
vendors putter has a different definition of its "too hot" temperature. 
   If you are
going to act on puters that are too hot, you might believe there is a 
heat problem
with a puter if you lump everything together, but I guess that's an 
operators choice.
It's not really clear to me that this query makes practical  sense even 
though it
seems like a logical query to want to make.

Note:     I' trying to provide puter health information so an operator can
easily query "platform.health.overall" to determine whether or not a puter
is healthy and if you really care why you can dig deeper into individual 
standard
puter components like "platform.health.fan", 
"platform.health.temperature",...
I think this would enable the kind of generic query across platforms 
that you
are thinking about.    Health is generated in a vendor and platform 
specific way
by interpretation of all the different sensors.   Other vendors than HP 
could
provide these meters and then the query you are proposing would make both
logical and practical sense.

>
>> 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.
>
Good.
> 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.
I understand wantng to name sensors based on how you want to
address them, but interpretation of them once you've addressed
them is going to vendor dependent.
> 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.

We have 2 use cases,
Get all the sensors within a given platform (based on ironic node id)
Get all the sensors of a given "type/name". independent of platform
Others?