Host Serial Console Logs via Redfish

[Brad Bishop]

Hi Nan

Thanks for this announcement.  I don't have a lot of specific feedback 
for you, but this sort of introduction to new content is super helpful 
for the overall health of OpenBMC.

On Mon, Mar 08, 2021 at 01:45:00PM -0800, Nan Zhou wrote:

>Implementation for Phase 1 is in
>https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39093. It is
>based on obmc-console, phosphor-hostlogger, and bmcweb. The basic idea is

I like how you are making use of these existing projects.

>that phosphor-hostlogger collects host serial console logs via obmc-console
>and generates tarballs in a rotation manner. These tarballs are then
>consumed and exposed by a new node in bmcweb log service.

Is it one console line per LogEntry?

>We propose the following methods to improve it.
>
>   - Method 1: *D-Bus Signal*; phosphor-hostlogger implements an interface
>   which contains a signal. The payload of the signal should contain
>   timestamps and log messages.  BmcWeb registers as a listener and once it
>   receives a signal, it populates a new LogEntry. BmcWeb should implement its
>   own configurable ring buffer to store log entries received from D-Bus.
>   - Method 2: *File Watcher*; add file watchers in BmcWeb to monitor the
>   log files produced by phosphor-hostlogger. This method is similar to method
>   1. But persistence is still a necessary condition.
>   - Method 3: *obmc-console + bmcweb*: install the console collection and
>   ring buffer parts of phosphor-hostlogger as a library. Use the library
>   directly in BmcWeb to collect console logs.
>   - Method 4: *phosphor-hostlogger + journal + rsyslog + bmcweb*: this
>   architecture is very similar to what the current OpenBMC uses for
>   redfish-event
>   <https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md>.
>   Add a new schema for log entries. Publish journal logs in
>   phosphor-hostlogger. Add file watchers in BmcWeb to monitor the log files
>   produced by rsyslog. rsyslog should have log rotation enabled. Persistence
>   is still a necessary condition.

Perhaps a missing option here is a single dbus object per LogEntry?  I'm 
not necessarily advocating for that - can I assume that was not 
considered because of performance/scaling concerns?

-brad