* Obtaining fan/temperature sensor status for Redfish
@ 2019-04-25 22:08 Shawn McCarney
2019-07-17 8:30 ` Alexander Amelkin
0 siblings, 1 reply; 3+ messages in thread
From: Shawn McCarney @ 2019-04-25 22:08 UTC (permalink / raw
To: openbmc
Hi,
The Redfish Thermal URI (/redfish/v1/Chassis/{ChassisId}/Thermal)
returns all the fan and temperature sensors within a chassis.
Each returned fan/temperature sensor contains a Status object with the
following properties:
* Health: Health state of the resource (OK, Warning, Critical)
* State: State of the resource (Absent, Disabled, Enabled, etc.)
Currently bmcweb always returns a Health value of "OK" and a State value
of"Enabled".
I would like to enhance bmcweb to return more accurate values in the
Status object when possible. Below I have summarized a proposed
design. Does this sound acceptable?
== Proposed Design ==
* Initially assume Redfish Status->Health value of "OK" and
Status->State value of "Enabled" as it does today.
* Use ObjectMapper associations to find the DBus inventory object path
that is related to the DBus sensor (if available).
* Get Functional property of
xyz.openbmc_project.State.Decorator.OperationalStatus interface for
inventory object path (if available).
* Set Redfish Status->Health to "Critical" if DBus Functional property
is false.
* Get Present property of xyz.openbmc_project.Inventory.Item interface
for inventory object path (if available).
* Set Redfish Status->State to "Absent" if DBus Present property is
false. Also remove the Redfish Status->Health property from the
response if Present is false.
== Notes ==
From the Redfish documentation I read, it was unclear whether the
Redfish Status object was intended to describe the sensor itself (such
as a fan controller chip) or the hardware being monitored by the sensor
(such as a fan).
It was also unclear what the value of the Status->Health property should
be for hardware that is not present.
I posted these questions to the Redfish forum:
* https://redfishforum.com/thread/187/intended-meaning-status-object-temps
Their responses were:
* Status is for the hardware being monitored, not the sensor itself.
* Status->Health should probably not be returned if hardware is not present.
Thanks,
Shawn McCarney
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Obtaining fan/temperature sensor status for Redfish
2019-04-25 22:08 Obtaining fan/temperature sensor status for Redfish Shawn McCarney
@ 2019-07-17 8:30 ` Alexander Amelkin
2019-07-17 12:12 ` Brad Bishop
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Amelkin @ 2019-07-17 8:30 UTC (permalink / raw
To: Shawn McCarney, openbmc
[-- Attachment #1.1: Type: text/plain, Size: 1838 bytes --]
26.04.2019 1:08, Shawn McCarney wrote:
> Hi,
>
> The Redfish Thermal URI (/redfish/v1/Chassis/{ChassisId}/Thermal) returns all the fan and temperature sensors within a chassis.
>
> Each returned fan/temperature sensor contains a Status object with the following properties:
> * Health: Health state of the resource (OK, Warning, Critical)
> * State: State of the resource (Absent, Disabled, Enabled, etc.)
>
> Currently bmcweb always returns a Health value of "OK" and a State value of"Enabled".
>
> I would like to enhance bmcweb to return more accurate values in the Status object when possible. Below I have summarized a proposed design. Does this sound acceptable?
>
> == Proposed Design ==
>
> * Initially assume Redfish Status->Health value of "OK" and Status->State value of "Enabled" as it does today.
> * Use ObjectMapper associations to find the DBus inventory object path that is related to the DBus sensor (if available).
> * Get Functional property of xyz.openbmc_project.State.Decorator.OperationalStatus interface for inventory object path (if available).
> * Set Redfish Status->Health to "Critical" if DBus Functional property is false.
My understanding was that 'Functional' property is for deactivation/activation of components in context of both health checking and hotplugging.
That is, I had an impression that it's the property that can be set by either the operator or the system software, so it's not necessarily a health status.
Correct me if I'm wrong, but to me it's more like it should map to State Enabled/Disabled without any reason implications. I think that health status must come from another source than the dbus 'Functional' property.
The rest sounds fine to me.
With best regards,
Alexander Amelkin,
Leading BMC Software Engineer, YADRO
https://yadro.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Obtaining fan/temperature sensor status for Redfish
2019-07-17 8:30 ` Alexander Amelkin
@ 2019-07-17 12:12 ` Brad Bishop
0 siblings, 0 replies; 3+ messages in thread
From: Brad Bishop @ 2019-07-17 12:12 UTC (permalink / raw
To: Alexander Amelkin; +Cc: Shawn McCarney, openbmc
at 4:30 AM, Alexander Amelkin <a.amelkin@yadro.com> wrote:
> can be set by either the operator or the system software
Can you elaborate on what made you think the operator could set operational
statuses?
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-17 12:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-25 22:08 Obtaining fan/temperature sensor status for Redfish Shawn McCarney
2019-07-17 8:30 ` Alexander Amelkin
2019-07-17 12:12 ` Brad Bishop
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.