Redfish Message Registry
Ed Tanous
ed at tanous.net
Sat Nov 14 09:01:41 AEDT 2020
On Fri, Nov 13, 2020 at 1:24 PM Rahul Kapoor <rahulkapoor at microsoft.com> wrote:
>
> Hi,
>
>
>
> Looking at bmcweb’s message registry implementation (openbmc_message_registry.hpp) I understand that each registry entry is purpose defined for a specific system event.
This registry is for where we need openbmc specific events, that
aren't modeled well in Redfish.
>
> I am looking for a generic registry entry (other than SELEntryAdded) that can be used for any discrete sensor and let the message arguments specify what discrete sensor it is associated with and other details. Following is what I am thinking
Redfish has no concept of a "Discrete" sensor. In general, what
would've been a discrete sensor in IPMI is modeled by a specific
Redfish property on a specific resource, so I suspect the thing you're
looking for here is the ResourceChanged event within the Resource
registry. DSP8011_2020.3, ResourceEvent.1.0.3.json is the newest
version of this registry, which we have implemented in bmcweb here:
https://github.com/openbmc/bmcweb/blob/74eec26b6ba3b14716db87cb8a837c33bdb69f62/redfish-core/include/registries/resource_event_message_registry.hpp#L83
>
>
>
> MessageEntry{"DiscreteSensorAlert_1",
>
> {
>
> "Indicates that a discrete sensor "
>
> "has critical alert condition met."
>
> "Additional information in Event"
>
> "data 1",
>
> "%1 discrete sensor raised alarm.\n"
>
> "Error=%2 \nEvent Data1=%3",
>
> "Critical",
>
> 3,
>
> {"string", "string", "number"},
>
> "Check the sensor or subsystem for errors.",
>
> }},
>
> MessageEntry{"DiscreteSensorAlert_2",
>
> {
>
> "Indicates that a discrete sensor "
>
> "has critical alert condition met"
>
> "Additional information in Event"
>
> "data 1 and 2",
>
> "%1 discrete sensor raised alarm.\n"
>
> "Error=%2 \nEvent Data1=%3 "
>
> "Event Data2=%4",
>
> "Critical",
>
> 4,
>
> {"string", "string",
>
> "number","number"},
>
> "Check the sensor or subsystem for errors.",
>
> }},
>
>
>
> Message id is of the form <ID>_<Event data fields>
>
>
>
> Let me know what you think
I think this use case is already covered by the base redfish
specification; We should use and implement that. What is defined
above is trying to impose IPMI (A totally different specification) on
top of Redfish. I would be against that, and in general, openbmc
tries to abstract the various transports from each other, under the
assumption that some systems use IPMI only, some systems use Redfish
only, and some use both, and we need to support all use cases.
>
>
>
> -Rahul Kapoor
>
>
More information about the openbmc
mailing list