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