Re: Adding support for custom SEL records

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

On Wed, Oct 19, 2022 at 09:50:47AM -0600, Bills, Jason M wrote:

> I'd also be curious about the reverse question.  Is there any benefit to 
> storing logs on D-Bus that makes it a better solution?
...
> Is there a way we can now get together and define a new logging solution
> that is fully upstream and avoids the drawbacks of both existing solutions?

First and foremost I'd like to see consistency come out of this.  If
there is another proposal for how to do it that we can all consolidate
on (and people are willing to put in effort to get there) then I'm
on-board.  It seems to me like the lowest friction way to get there, with
the best maintainability, is to use the phosphor-logging APIs even if we
end up not putting them into d-bus entries.

It happens that phosphor-logging stores the instances on d-bus, but the
more important aspect to me is that we have a more consistent API for
defining and creating errors and events.  The "rsyslog-way" is that you
make very specific journal entries that the rsyslog magic knows about,
but there are a few issues with it:

    1. We don't have any consistency in what, when, and how events are
       logged.  We even have cases within the same repository (looking at
       dbus-sensors) where some of the implementations make the magic
       SEL records and others do not.  Additionally, they're not required
       to be the same format.  Some maintainers have even outright
       rejected patches with the "magic log statements".

    2. There is no way to generate something like a Redfish message
       registry for the events, because they're just arbitrary strings
       that are sprinkled around.  It isn't even easy to programatically
       search the code for them because there are 4 different approaches
       to that: cout/cerr, direct journald, phosphor-logging "v1", and
       phosphor-logging lg2.

    3. Any kind of automation around these is more at the whim of
       whatever the developers / maintainers decide to change.  It is,
       for example, really difficult for me to write data center tooling
       that reacts to events like "we just lost pgood to the host"
       because I have to read through the code to find the specific text
       and hope it never changes.

Conversely, the phosphor-logging APIs leverage YAML-based error specifiers,
which can be easily transposed into a Redfish message registry, and happen
to also be the same structure we use for inter-process errors on d-bus calls.
While I have to review the implementations to make sure they're
appropriately created, I have far less concern about them disappearing
or changing once they are in place (and I can review the changes to the YAML
specifiers to keep tabs on what changes their might be).

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]