Redfish EventService Implementation
Bills, Jason M
jason.m.bills at linux.intel.com
Thu Jun 18 03:19:35 AEST 2020
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
>
More information about the openbmc
mailing list