Re: Redfish EventService Implementation

["Bills, Jason M" <jason.m.bills@linux.intel.com>]

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.

> 
> 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
>