Re: Redfish EventService Implementation

[James Feist <james.feist@linux.intel.com>]

On 6/16/2020 8:24 AM, Patrick Williams wrote:
> 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.
> 
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.