Redfish EventService Implementation

[Patrick Williams]

On Wed, Jun 17, 2020 at 05:38:47PM +0530, Ratan Gupta wrote:
> Hi James,Pattrick.
> 
> >> Can't we do this already today by defining a simple errors/metadata file
> >> in phosphor-dbus-interfaces and calling 'logging::report<...>' on it?
> >> This will create a record on dbus in phosphor-logging.
> >>
> > I think the original concern was with supporting on the order of 
> > 10,000 log entries, having this on d-bus seemed impractical. Also the 
> > free log rotation the journal provides is useful. Now modifying the 
> > logging::report<...> to conditionally log to the journal seems realistic.
> 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.

Good.  This wasn't clear from the earlier email.  Thanks.


> As we are in agreement that we want to use the journal for persistence 
> and log rotate feature.

I'm not convinced there is agreement on this.  There has been
disagreement about even using the journal for phosphor-logging use since
the beginning and I suspect there would be less agreement on another
application using it as its own IPC mechanism.

Just because a hammer can be used to insert a nail into a board doesn't
mean you use it insert any pointy thing into a flat thing.  [ Just
because the journal provides log rotation and persistance doesn't mean
you should use it for every feature needing log rotation and
persistance. ]


> ***** 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. ******

I don't know Redfish well, so bear with me if there is something obvious
I'm missing.  But, the first part of this "requirement" doesn't seem to
follow from the second part of the "requirement" to me.

Sending a signal of a property changing to the Redfish clients is
straight-forwawrd; Redfish should subscribe to all the appropriate
dbus-events.  I don't understand how this implies any sort of logging.
Where does the logging part of this requirement come from?

> 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.

#2 is absolutely unworkable on the surface to me.  log::report is to
create a error entry (xyz.openbmc_project.Logging.Entry), which creates
a dbus-object, which would cause log::report to be called, which creates
a dbus-object, which ...

Even if what you meant was something like logging::log<info>, this seems
pretty heavy.  I'm not sure this is something that can be inserted into
sdbusplus, especially for the ASIO-based object servers, because in many
cases applications register their own callback.  For the sdbus++
generated server bindings we could squeeze it in.  But, what you're
proposing here is essentially a "journal-as-dbus-monitor".  We'd
certainly need to make some measurements on how many kB/s worth of
journal entries this would create because I suspect we could end up
burning out a NAND flash with as many writes as that would induce.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200617/0c45ecdc/attachment.sig>