Redfish EventService Implementation

[James Feist]

> My intention was not to re-implement the logging, my intention was to 
> extend/use the existing design which we already have it below.
> 
> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md 
> 
> 
> I was trying not to bring the Redfish specific stuff in each individual 
> repo, instead each transport can listen for
> Dbus events and write to the journal which goes to their app specific file.
> 
> Your point is valid that we would be polluting the journal if each and 
> every transport start writing as per their needs.
> 
> ***** As per the Redfish one of the requirement is we need the log for 
> most of the Dbus Property update/interface added as they
> are mapped to some Redfish Resource and the bmcweb has to send the 
> Resource updated/modified signal to the
> Redfish client. ******
> 
> As we are in agreement that we want to use the journal for persistence 
> and log rotate feature.
> 
> We have two options:
>      1) Each transport interface listens for the Dbus signals and write 
> it to their app specific file.
>      2) Each openbmc repo must use log::report for each D-bus property 
> update/ interface added.

I'm assuming you meant each event added right? I don't see any reason 
that the logs have anything to do with d-bus, except maybe if it seems 
worth it for phosphor-logging to catch all the reports and log them to 
the journal. Although it would probably be more efficient (and easier 
for phased adoption) to just make the log::report call write to the 
journal as well.

>         To make this happen, we need the following
>          * common message format which can be used by the all other 
> application (SEL,Redfish) etc.

Agree.

>          * Transport application will read this common message from the 
> journal and use it as per their needs.
> 
> Option no 2:   It is ideal solution but that requires good amount of 
> work as
>               either each and every D-bus repo  should write to the 
> journal for any property update/interface added.

Why every property/interface added? This would make the logs much to 
large to be useful. And many times the information needed is specific to 
the log type. For instance a event for inventory discovered might need 
the type of inventory, the serial number, the model, etc. To get all 
that information would be multiple interfaces added events combined 
together. It would make more sense in this aspect for the inventory 
daemon to take the parts out of say the Asset, and Chassis interfaces 
along with the path identifier, and create an entry in the log that is 
use-able. It would be much more difficult and error-prone for the 
Redfish or SEL daemon to try to piece these multiple events together to 
form something useful.

>                       or
>               Should SDbusplus do this as each and every application 
> uses the sdbusplus framework to manage the dbus objects
> 
> Please let me know your thoughts.
> 
> Ratan
>