Redfish EventService Implementation

[James Feist]

On 7/12/2020 11:32 PM, Ratan Gupta wrote:
> Hi James,
> 
> As you asked for the examples in the 
> thread(https://lists.ozlabs.org/pipermail/openbmc/2020-June/022125.html), I 
> have created the mapping at the following location.
> 
> https://gist.github.com/ratagupt/0aa4da098a60d49af90a7e4a6ea6d5f2

Thanks for the examples.

> 
> 1) Map1: Mapping between redfish resources to Dbus resources

How does this work when the mapping isn't 1:1 vs D-Bus? Most of the time 
the enums to not match the d-bus enum, or take multiple d-bus interface 
to distinguish what the value should be. Also how does this work for 
discovered things, like multiple chassis?


> 2) Map2: Mapping between redfish resource types to the ineterested Dbus 
> interfaces
> 3) Map3: Mapping between Dbus resources to redfish resources
> 
> 
> I tried to cover the following scenario in the above mapping.
> 
> * Redfish resource is mapped to multiple Dbus Resources
> * Redfish Property is mapped to single Dbus property
> * Redfish Property(complex property) is mapped to multiple dbus property.
> * Same type of Redfish Resources are mapped to different Dbus Resources
> * Redfish node url having multiple regex : Yet to take a look on this.
> >
> Flow would be like as below
> 
> => In bmcweb each Redfish node represents to a Redfish Resource.
> => Each node will be having it's own mapping between Redfish properties 
> and the Dbus Resources.
> 
> => Some code on bmcweb will walkthrough on each node during startup , 
> get this mapping from each node and generate
>     two mappings
>     1) Reverse mapping (Dbus Resource to Redfish Resource)(MAP3) and
>     2) mapping between Resource Types to the interested Dbus 
> interfaces(MAP2)
> 
> => To start with we will support few resource types and then scale it up 
> as needed.

I think we need an idea of what the final solution will look like for 
more complicated properties, or we'll be creating something that isn't 
future proof.

> 
> => Map2 would be used when the Redfish client subscribe for the 
> ResourceType to get the Dbus mappings.
> 
> => Map3 would be used when the Dbus signal gets generated and need the 
> Redfish mappings.

Why can't these be the same mapping? I think having 3 different maps 
makes this very confusing. I also think this is attempting to generalize 
the problem too early. If you look at the Redfish code to determine some 
of the more complicated properties, sometimes it takes quite a bit of 
logic. That logic also would possibly be nice to reuse. Maybe we can 
take your idea of a match with a callback to some of the already 
existing property parsing? Obviously it would need some cleaning up, but 
I could see something with a map of schemas/properties to function 
pointers for property parsing.

> 
> => Once we have all thsese mapping gets generated and loaded into the 
> memory, bmcweb would start listening
>     for the interfaces listed in map2.

Why aren't these compiled in? I don't see why they need to be loaded, 
could just be in code. Also, they shouldn't be added as matches until 
there is a subscriber, or we'll add many unneeded matches.

> 
> => Once any Dbus signal gets generated map3 would be used to get the 
> Redfish mapping.
> 
> Please let me know if you have any concerns with this approach.
> 
> Ratan