[Ipmitool-devel] ipmitool 'ok' output in sdr list

[Albert Chu]

Hello,

Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
that a sensor says 'ok', but FreeIPMI outputs that something is wrong
with a sensor."

After investigation, it appears that ipmitool's output with 'sdr list'
lists 'ok' for many (all?) discrete sensors regardless of the contents
of that reading. As long as the reading is available and valid, it
outputs "ok". For example, here's a power supply sensor I got on a node
here.

PSU 1 Status | 0x0b | ok

0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
Yet it still says 'ok'.

In FreeIPMI, it states

54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected' 'Power Supply Failure detected' 'Power Supply input lost (AC/DC)'

So there's something wrong w/ this power supply or its atleast worth
investigating for the staff.

At minimum, the "ok" output appears to confuse some users. At worst,
some users may think the sensor readings are good when they are in fact
not. Perhaps an output of "N/A" would be more appropriate for discrete
sensors in this case?

Obviously there's a lot of history in this output with ipmitool, but I
thought I'd mention it for discussion.

Al

[Jarrod B Johnson]

Speaking of this phenomenon, in pyghmi I was working with the idea of
assigning a rough value for the various discrete sensors.

My effort is in the 'discrete_type_offsets' structure in:
https://github.com/stackforge/pyghmi/blob/master/pyghmi/ipmi/private/constants.py


It may be imperfect, so looking for opinions on the validity of this.


From: Albert Chu <***@llnl.gov>
To: ipmitool-***@lists.sourceforge.net
Date: 09/26/2014 02:12 PM
Subject: [Ipmitool-devel] ipmitool 'ok' output in sdr list



Hello,

Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
that a sensor says 'ok', but FreeIPMI outputs that something is wrong
with a sensor."

After investigation, it appears that ipmitool's output with 'sdr list'
lists 'ok' for many (all?) discrete sensors regardless of the contents
of that reading. As long as the reading is available and valid, it
outputs "ok". For example, here's a power supply sensor I got on a node
here.

PSU 1 Status | 0x0b | ok

0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
Yet it still says 'ok'.

In FreeIPMI, it states

54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected' 'Power
Supply Failure detected' 'Power Supply input lost (AC/DC)'

So there's something wrong w/ this power supply or its atleast worth
investigating for the staff.

At minimum, the "ok" output appears to confuse some users. At worst,
some users may think the sensor readings are good when they are in fact
not. Perhaps an output of "N/A" would be more appropriate for discrete
sensors in this case?

Obviously there's a lot of history in this output with ipmitool, but I
thought I'd mention it for discussion.

Al

--
Albert Chu
***@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

[Jim Mankovich]

Al,

As you pointed out 'ok' simply means the sensor itself is operational (a
reading is available and
valid). It is not an interpretation of the "goodness" of the Sensor
Reading. This is the way "ok"
should be interpreted in this ipmitool output. I would agree that it
would be helpful if ipmitool
interpreted the status for discrete sensors to provide more information,
but right not it does not.
If you understand what "ok" means, then there is really no need for
'N/A' as even for non-discrete
sensors "ok" does not mean that the returned Sensor Reading is not above
or below an alarm
threshold. If you want more detailed information about the sensor
use, sdr list -c, or sdr list -v.

Thanks for the feedback,
Jim

Post by Albert Chu
Hello,
Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
that a sensor says 'ok', but FreeIPMI outputs that something is wrong
with a sensor."
After investigation, it appears that ipmitool's output with 'sdr list'
lists 'ok' for many (all?) discrete sensors regardless of the contents
of that reading. As long as the reading is available and valid, it
outputs "ok". For example, here's a power supply sensor I got on a node
here.
PSU 1 Status | 0x0b | ok
0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
Yet it still says 'ok'.
In FreeIPMI, it states
54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected' 'Power Supply Failure detected' 'Power Supply input lost (AC/DC)'
So there's something wrong w/ this power supply or its atleast worth
investigating for the staff.
At minimum, the "ok" output appears to confuse some users. At worst,
some users may think the sensor readings are good when they are in fact
not. Perhaps an output of "N/A" would be more appropriate for discrete
sensors in this case?
Obviously there's a lot of history in this output with ipmitool, but I
thought I'd mention it for discussion.
Al
--

[dan farmer]

Jim -

It may be true that experts know how to interpret the results. But for
the other 99.999999% of the planet, “ok” means things are going alright,
that it’s a green check in the box kind of thing. I know the IPMI protocol
reasonably well and have run the ipmitool on many, many systems, as well
as written output parsers and read the man page and some of the source code,
but I personally had no idea that OK didn’t mean some sort of all-clear
A-OK thing. Now obviously you could say I’m not the brightest bulb in the
box, and I’m certainly not the most detail oriented reader, but at the least
I’m one data point.

I realize that changing a venerable tool that has been encoded in many a
script and parsed to kingdom come is not something to do lightly, but I’d
also bet those same parsers display it as a green light or something
positive rather than the intended meaning.

I don’t think that anyone would suggest that the creators of the tool are
trying to deceive or fool others with the output, but I’d strongly suggest
that the Powers That Be reflect on what is actually meant. If you were to
suggest today that the tool should say “ok” instead of a former value I
think you’d get laughed at, it’s simply an absurd injustice of information
dissemination.

dan

Post by Jim Mankovich
Al,
As you pointed out 'ok' simply means the sensor itself is operational (a
reading is available and
valid). It is not an interpretation of the "goodness" of the Sensor
Reading. This is the way "ok"
should be interpreted in this ipmitool output. I would agree that it
would be helpful if ipmitool
interpreted the status for discrete sensors to provide more information,
but right not it does not.
If you understand what "ok" means, then there is really no need for
'N/A' as even for non-discrete
sensors "ok" does not mean that the returned Sensor Reading is not above
or below an alarm
threshold. If you want more detailed information about the sensor
use, sdr list -c, or sdr list -v.
Thanks for the feedback,
Jim

Post by Albert Chu
Hello,
Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
that a sensor says 'ok', but FreeIPMI outputs that something is wrong
with a sensor."
After investigation, it appears that ipmitool's output with 'sdr list'
lists 'ok' for many (all?) discrete sensors regardless of the contents
of that reading. As long as the reading is available and valid, it
outputs "ok". For example, here's a power supply sensor I got on a node
here.
PSU 1 Status | 0x0b | ok
0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
Yet it still says 'ok'.
In FreeIPMI, it states
54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected' 'Power Supply Failure detected' 'Power Supply input lost (AC/DC)'
So there's something wrong w/ this power supply or its atleast worth
investigating for the staff.
At minimum, the "ok" output appears to confuse some users. At worst,
some users may think the sensor readings are good when they are in fact
not. Perhaps an output of "N/A" would be more appropriate for discrete
sensors in this case?
Obviously there's a lot of history in this output with ipmitool, but I
thought I'd mention it for discussion.
Al
--

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

[Hank Bruning]

Dan,
Jim is correct that in the context of ipmitool a sensor reading is
available.
If It is not ok there was a bus error, IPMC at the IPMB was removed or the
sensor is undergoing initialization. All situations where the sensor
Event1, Event 2 or Event 3 data is unavailable
If you get an ok then you can then process the data according the Compact
or Full sensor record.
Hank Bruning
JBlade

Post by dan farmer
Jim -
It may be true that experts know how to interpret the results. But for
the other 99.999999% of the planet, “ok” means things are going alright,
that it’s a green check in the box kind of thing. I know the IPMI protocol
reasonably well and have run the ipmitool on many, many systems, as well
as written output parsers and read the man page and some of the source code,
but I personally had no idea that OK didn’t mean some sort of all-clear
A-OK thing. Now obviously you could say I’m not the brightest bulb in the
box, and I’m certainly not the most detail oriented reader, but at the
least
I’m one data point.
I realize that changing a venerable tool that has been encoded in many a
script and parsed to kingdom come is not something to do lightly, but I’d
also bet those same parsers display it as a green light or something
positive rather than the intended meaning.
I don’t think that anyone would suggest that the creators of the tool are
trying to deceive or fool others with the output, but I’d strongly suggest
that the Powers That Be reflect on what is actually meant. If you were to
suggest today that the tool should say “ok” instead of a former value I
think you’d get laughed at, it’s simply an absurd injustice of information
dissemination.
dan

Post by Jim Mankovich
Al,
As you pointed out 'ok' simply means the sensor itself is operational (a
reading is available and
valid). It is not an interpretation of the "goodness" of the Sensor
Reading. This is the way "ok"
should be interpreted in this ipmitool output. I would agree that it
would be helpful if ipmitool
interpreted the status for discrete sensors to provide more information,
but right not it does not.
If you understand what "ok" means, then there is really no need for
'N/A' as even for non-discrete
sensors "ok" does not mean that the returned Sensor Reading is not above
or below an alarm
threshold. If you want more detailed information about the sensor
use, sdr list -c, or sdr list -v.
Thanks for the feedback,
Jim

Post by Albert Chu
Hello,
Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
that a sensor says 'ok', but FreeIPMI outputs that something is wrong
with a sensor."
After investigation, it appears that ipmitool's output with 'sdr list'
lists 'ok' for many (all?) discrete sensors regardless of the contents
of that reading. As long as the reading is available and valid, it
outputs "ok". For example, here's a power supply sensor I got on a node
here.
PSU 1 Status | 0x0b | ok
0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
Yet it still says 'ok'.
In FreeIPMI, it states
54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected'

'Power Supply Failure detected' 'Power Supply input lost (AC/DC)'

Post by Jim Mankovich

Post by Albert Chu
So there's something wrong w/ this power supply or its atleast worth
investigating for the staff.
At minimum, the "ok" output appears to confuse some users. At worst,
some users may think the sensor readings are good when they are in fact
not. Perhaps an output of "N/A" would be more appropriate for discrete
sensors in this case?
Obviously there's a lot of history in this output with ipmitool, but I
thought I'd mention it for discussion.
Al
--

------------------------------------------------------------------------------

Post by Jim Mankovich
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

Post by Jim Mankovich
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel