Redfish EventService Implementation

[Andrew Geissler]

> On Jun 17, 2020, at 12:19 PM, Bills, Jason M <jason.m.bills at linux.intel.com> wrote:
> 
> 
> 
> On 6/17/2020 5:08 AM, Ratan Gupta wrote:
>> Hi James,Pattrick.
>> Thanks for giving the feedback
>> On 6/16/20 9:41 PM, James Feist wrote:
>>> 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.
>> My intention was not to re-implement the logging, my intention was to extend/use the existing design which we already have it below.
>> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md I was trying not to bring the Redfish specific stuff in each individual repo, instead each transport can listen for
>> Dbus events and write to the journal which goes to their app specific file.
>> Your point is valid that we would be polluting the journal if each and every transport start writing as per their needs.
>> ***** As per the Redfish one of the requirement is we need the log for most of the Dbus Property update/interface added as they
>> are mapped to some Redfish Resource and the bmcweb has to send the Resource updated/modified signal to the
>> Redfish client. ******
> Why do we want to log on D-Bus property updates?  This seems like it will be too noisy for the EventLog.

I don’t think it would be all, just the one’s the different transport layers need.

So to get my head straight on this, there is a commit in state-manager to log
the redfish events to the journal:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-state-manager/+/33494

With what Ratan proposed above, we have two options?
1) A separate application that listens for the chassis properties to change and logs those
    events to the journal in the format the transport layer wants
2) Code within phosphor-state-manager that logs a generic event to the
    journal which then can be post processed by the different transport 
    layer code.

> 
>> As we are in agreement that we want to use the journal for persistence and log rotate feature.
>> We have two options:
>>     1) Each transport interface listens for the Dbus signals and write it to their app specific file.
>>     2) Each openbmc repo must use log::report for each D-bus property update/ interface added.
>>        To make this happen, we need the following
>>         * common message format which can be used by the all other application (SEL,Redfish) etc.
>>         * Transport application will read this common message from the journal and use it as per their needs.
>> Option no 2:   It is ideal solution but that requires good amount of work as
>>              either each and every D-bus repo  should write to the journal for any property update/interface added.
>>                      or
>>              Should SDbusplus do this as each and every application uses the sdbusplus framework to manage the dbus objects
>> Please let me know your thoughts.
>> Ratan