Redfish EventService Implementation

[Brad Bishop]

On Tue, 2020-06-23 at 12:57 +0530, Ratan Gupta wrote:
> 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)

It probably doesn't make sense to have any json files.  The application
logic itself does the mapping.

> 3) 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.
> 
> 4) bmcweb would monitor the DBUS events
> 
> 5) Get the Redfish Path from the Mapping(3) and send the Redfish event

Let me try to restate 3-5.  We already have application logic in bmcweb
that maps redfish resources to dbus interfaces, triggered by redfish
client requests (like a GET or PATCH).  The proposal here I think is to
implement the reverse - add application logic in bmcweb that maps dbus
interfaces to redfish resources, triggered by dbus signals.  I think
this is more or less what was suggested by Patrick?

> Don't we, in effect, have the mapping from Redfish to dbus by nature
> of the Redfish providers that create their content from dbus objects?

> James, Apparao: Please let me know if there is any more concern with 
> this approach.

Ratan you had 2x #2s in the flow above, which I fixed.  Please let me
know if I got it wrong.

The main concerns with this approach that I have heard are too many
signal matches and complexity of the logic implementing the reverse map.
I can definitely see how the logic will get complicated given our
current dbus data model.

One idea floating around to address these is inventing a journal
metadata scheme that is management interface agnostic.  I understand the
motivation behind that - it is much simpler for an application to slide
a single journal entry into the journal with all the metadata needed to
generate events, than it is for an application to snoop multiple signals
off dbus and pull events out of that.

But I wonder if inventing a management interface agnostic scheme for
adding events to the journal is really just inventing a new data model
for how we represent things in a server - e.g. are we just working
around our dbus data model?  Maybe we should fix it instead, so that it
isn't so difficult for applications to use it?  With that said I don't
know how to do this and I could use more concrete details on which areas
of the data model make it hard to consume signals.  Does anyone have any
ideas or examples?