Redfish EventService Implementation

Patrick Williams patrick at stwcx.xyz
Wed Jun 17 01:24:28 AEST 2020


On Mon, Jun 15, 2020 at 02:42:11PM -0700, James Feist wrote:
> On 6/15/2020 5:50 AM, Ratan Gupta wrote:
> >      eg:
> >          sd_journal_send("MESSAGE=%s", "Account Modified",
> >              "PRIORITY=%i", LOG_INFO, "REDFISH_MESSAGE_ID=%s",
> > "REDFISH_RESOURCE_PATH=/redfish/v1/AccountService/accounts/<id>",
> >              "REDFISH_RESOURCE_TYPE=ComputerSystem"
> >              "REDFISH_REGISTRY_PREFIX=Task/Base/Resource/Oem",
> >              "REDFISH_MESSAGE_ARGS=%s", "Off", NULL);
> 
> If we're going to go down the path of re-implementing logging, I think 
> the goal should be to stop logging things in the Journal that are 
> Redfish specific, and instead log them in some generic format that 
> phosphor logging controls the map. Right now we are bifurcated because 
> the dbus-event-logs, SEL, PEL, and Redfish are all using different 
> methods of logging, that play to their own set of rules. 

Absolutely agree with you here.  There is zero reason that applications
should start logging specially formed messages with REDFISH_* meta-data.
We shouldn't have any applications explicitly know about Redfish except
the Redfish providers themselves.  This is no different from IPMI, PLDM,
or any other external interface.

The kind of information presented here as being interesting to expose
via Redfish is equally as interesting to me to be able to add to one of
our 'FFDC dumps', which could be used for security / forensic work.

> Most repos use 
> phosphor-logging, so instead of creating yet another daemon, if we added 
> support to create a 'System Level' or 'External User' log that has 
> predefined dictionaries of required and optional keys, something like 
> phosphor-dbus-interfaces, we might be able to drop some of these 
> transport specific logs, and have the transports based on the same 
> database (the journal). Then each transport could filter these based on 
> journal entry type, and transform them into the correct log for that 
> transport. I think adding more Redfish specifics into the logs hinders 
> those who do not want Redfish in their systems.

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.

-- 
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/20200616/61f60233/attachment-0001.sig>


More information about the openbmc mailing list