Open Stack

On Thu, 16 Oct 2014, Jim Mankovich wrote:

> What I would like to propose is dropping the ipmi string from the name 
> altogether and appending the Sensor ID to the name  instead of to the 
> Resource ID.   So, transforming the above to the new naming would result in 
> the following:

> | Name                                     | Type  | Unit | Resource ID
> | hardware.current.power_meter_(0x16)      | gauge | W    | edafe6f4-5996-4df8-bc84-7d92439e15c0
> | hardware.temperature.system_board_(0x15) | gauge | C    | edafe6f4-5996-4df8-bc84-7d92439e15c0

[plus sensor_provider in resource_metadata]

If this makes sense for the kinds of queries that need to happen then
we may as well do it, but I'm not sure it is. When I was writing the
consumer code for the notifications the names of the meters was a big
open question that was hard to resolve because of insufficient data
and input on what people really need to do with the samples.

The scenario you've listed is getting all sensors on a given single
platform.

What about the scenario where you want to create an alarm that says
"If temperate gets over X on any system board on any of my hardware,
notify the authorities"? Will having the "_(0x##)" qualifier allow that
to work? I don't actually know, are those qualifiers standard in some
way or are they specific to different equipment? If they are different
having them in the meter name makes creating a useful alarm in a
heterogeneous a bit more of a struggle, doesn't it?

Perhaps (if they are not standard) this would work:

  | hardware.current.power_meter | gauge | W | edafe6f4-5996-4df8-bc84-7d92439e15c0

with both sensor_provider and whatever that qualifier is called in the
metadata?

Then the name remains sufficiently generic to allow aggregates across
multiple systems, while still having the necessary info to narrow to
different sensors of the same type.

> I understand that this proposed change is not backward compatible with the 
> existing naming, but I don't really see a good solution that would retain 
> backward compatibility.

I think we should strive to worry less about such things, especially
when it's just names in data fields. Not always possible, or even a
good idea, but sometimes its a win.

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent