Redfish EventService Implementation
James Feist
james.feist at linux.intel.com
Thu Jun 25 02:24:03 AEST 2020
> I have got an update from the DMTF that persistence is not required to
> be implemented for the
> events(https://redfish.dmtf.org/schemas/v1/Event.v1_5_0.json),
> which implies we don't need to log the events in Journal.
>
> More info(https://github.com/DMTF/Redfish/issues/3646)
>
> Now updating the proposal where redfish client subscribed for Resource
> Type based events
> 1) Client would subscribe for the Redfish Resource(eg:ManagerAccount) to
> receive events like Account add/delete/modify
> Hence need for mapping from (RedfishResource to Dbus Resource)
>
> 2) Have the mapping info from Redfish resources to DBUS Resources (Some
> JSon file may have this mapping)
This assumes the mapping is static, which on many systems it isn't,
right? I think this needs to be developed to see what it would be like.
>
> 2) Have the reverse mapping from DBUS Resources to Redfish Resources
> * This is needed to send the Redfish event if there is any changes
> in the corresponding D-bus resources.
> eg BMC state change/network change etc.
>
> 3) bmcweb would monitor the DBUS events
Which events specifically? It seems like it would be monitoring lots of
events in this proposal. Some examples could be useful.
>
> 4) Get the Redfish Path from the Mapping(2) and send the Redfish event
>
> 5) Bmcweb would buffer N number of events that can be configurable by
> redfish client. Buffer would get cleaned up in case of bmcweb restart or
> BMC reset.
>
Can you please push a patch to the event service design doc with the
change to the design you'd like? Some examples in the design would help
with understanding the proposal. This thread is quite long and hard to
follow for someone not involved, it'd be good to document the proposed
changes.
https://github.com/openbmc/docs/blob/master/designs/redfish-eventservice.md
More information about the openbmc
mailing list