Redfish EventService Implementation

[Ratan Gupta]

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

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