Redfish EventService Implementation

[James Feist]

On 6/15/2020 5:50 AM, Ratan Gupta wrote:
> Hi James/Apparao/Brad,
> 
> I am inclining towards having a separate application for Redfish 
> Logs(like: phosphor-sel-logger),
> This application does the following.
> 
> 1) Have the mapping info from Redfish resources to Dbus Resources
>       * This is needed as webserver have to provide the event filtering 
> through Resource Type
>       * eg : Redfish Client may ask as the client is interested in 
> "Account" Resource type
>              i.e all the user account related updates should be given to 
> redfish client.
>              which suggest that there should be mapping from Redfish 
> Resource to Dbus Resource
> 
> 2) Have the reverse mapping from Dbus Resources to Redfish Resources
>       * This is needed to send the Redfish event if there is any changes 
> in the
>         corresponding D-bus resources. eg BMC state change/network 
> change etc.
> 
> 3) This application monitors the D-bus event and Log the event in the 
> journal like below

Why do we need a listener on d-bus if the application creating the event 
already knows all the information? Why can't it log straight to the journal?

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

> 
> 4) rsyslogd will put all these logs from journal into "/var/log/redfish" 
> file.
> 
> 5) bmcweb/webserver would inotify this file location and on notification 
> it will send redfish event
> 
> 6) Event filtering would be done at the bmcweb/webserver side.
> 

I think this will probably be needed if we want one source of truth for 
logs.

> 
> We already have the infrastructure for seq no 4 and seq no 5 and we 
> wanted to leverage this infrastructure.
> 
> Please let me know if there is any concern with this approach.
> 
> Ratan
> 
> On 6/9/20 6:28 AM, James Feist wrote:
>> On 6/8/2020 2:08 PM, Brad Bishop wrote:
>>> On Sat, 2020-02-01 at 02:23 +0530, RAJESWARAN THILLAIGOVINDAN wrote:
>>>> Hi,
>>>>
>>>> I am going through the bmcweb code for implementing Redfish
>>>> EventService based on the design document
>>>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749. This design
>>>> is hooked to the journal based Redfish Event Logging.
>>>
>>> Would anyone else be willing to opine on whether or not they think
>>> journal based event schemes are what we want going forward for OpenBMC?
>>>
>>> My feeling is that they are not - as an alternative IPC mechanism don't
>>> we end up re-implementing things that DBus already does? Doesn't it
>>> require us to raise the same event twice everywhere (Once with DBus, and
>>> once in the journal)?  What does journal based eventing do that DBus
>>> signals don't do?
>>
>> We don't host log events on DBus at all, so there is no duplicate. The 
>> journal gives built in persistence and rotating of logs for large 
>> number of events. I know when this came up the last time one of the 
>> big issues was supporting thousands of logs wouldn't work well on DBus.
>>
>>
>>>
>>> Please poke holes.
>>>
>>> thx - brad
>>>