OpenBMC Logging Implementations: Interfaces and Error Messaging

[Matt Spinler]

On 1/25/2021 1:47 PM, Ed Tanous wrote:
> On Mon, Jan 25, 2021 at 11:05 AM Giles, Joshua <Joshua.Giles at dell.com> wrote:
>> Hello All,
>>
>>
>>
>> We’re hoping to get clarity in two areas of Logging with the aim of proposals to benefit all.
>>
>> These are interfaces and error messaging…
>>
>>
>>
>> Logging interfaces
>>
>> ===============
>>
>> Webui-vue appears to only display redfish Event Logging whereas “legacy” phosphor-logging is used by things such as generating SNMP traps.
>>
>>
>>
>> Question: Will legacy event logging be deprecated in OpenBMC in favor of Redfish logging?  If not, do we merely access legacy logging out-of-band via rsyslog?

I'll just mention that at the very least IBM will be using the 
phosphor-logging event logs for the foreseeable future due to some 
requirements on how we handle service for HW errors.  bmcweb already has 
the ability to convert those event logs into Redfish logservice events.  
At the moment they aren't combined with a message registry, but we plan 
to eventually add that.


>>
>>
>> Error Messaging
>>
>> =============
>>
>> There appears to be some duplicate/unique error messages amongst the two implementations:
>>
>> Phosphor-dbus-interfaces: e.g. https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Threshold/Critical.interface.yaml
>> Redfish message registry: e.g. https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/34510/4/redfish-core/include/registries/openbmc_message_registry.hpp (SensorThreshHoldCriticalGoingHigh)
>>
>>
>>
>> Question: Will the unique “legacy” errors defined in the phosphor-dbus-interfaces be available in the redfish message registry?  Is there a plan to consolidate these moving forward?
> I have no plans for this, nor have I seen a design for consolidating
> the two.  Today, they're different because Redfish log endpoints have
> very different requirements than phosphor-logging interfaces were able
> to provide, with that said, I'm open to there being a much simpler
> design that could work well here, I just haven't applied a lot of
> brainpower to trying to get them consolidated.
>
>>
>>
>> -Josh Giles