Redfish EventService Implementation

[Ratan Gupta]

Hi Apparao,

On 2/20/20 12:49 AM, Puli, Apparao wrote:
> Hi,
>
>   I am sorry for late response as this mail is buried under and got 
> struck back of my mind.
>
> As i did mentioned in EventService design document, EventLog Monitor 
> service is not common across the organizations( Example: Intel uses 
> the redfish event logs file and inotify mechanism for monitoring the 
> event logs. Where as IBM uses d-bus event log mechanism and they can 
> relay on match rules). That said challenges with ResourceType mapping 
> will be different in both monitoring mechanisms. This is good point. 
> Initially when i started EventService design, i thought we can have 
> mapping in bmcweb for ResourceTypes with set of MessageID's for Logged 
> events ( As per Intel design) but not sure that may become difficult 
> when we expand supported ResourceTypes.

If I am getting correctly, Here is the flow which Intel uses.

 1. Individual repo have to push the logs using sd_journal_send which
    will write to the file(/var/log/redfish) by using rsyslog daemon

sd_journal_send("MESSAGE=%s","journal text","PRIORITY=%i", <LOG_LEVEL>,
                 "REDFISH_MESSAGE_ID=%s",
                 "ResourceEvent.1.0.ResourceCreated",NULL);

      * How you would populate the "OriginOfCondition" during sending of
        event? (https://redfish.dmtf.org/schemas/v1/Event.v1_4_1.json)

      * Any plan to add resource path in this journal message which
        tells that this is the path for which resource created event
        generated.

      * Would the path be "Redfish Path/ D-bus Path"?

      * Where the mapping would be done between D-busPath/Redfish
        Resource path?

     
          Cons: Every application have to make the change(use sd_journal_send).
          My thought is backend application should not be aware of the redfish terminlogy.

*2.* Some application(bmcweb) would do the Inotify on the 
path(/var/log/redfish) and send the event once there is any activity on 
this file.

> I thought we can have mapping in bmcweb for ResourceTypes with set of MessageID's for Logged events ( As 
per Intel design)

     Can you explain more here. What is your plan? How you would do the Resource Type based event filtering?REDFISH_MESSAGE_ID is different than the resource type.

>
> As per my reading from below query, You are looking at d-bus match 
> rules and ResourceTypes mapping which is more specific to d-bus event 
> logging(IBM way of implementing event logging). reading it from 
> journal logs will give more information but that will impact the 
> performance to large extent. This might be one of the reason why we 
> (Intel) uses Redfish message ID while logging redfish events logs to 
> journal(You can refer design document for same at 
> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md). 
> In opinion, in your d-bus if you are using some kind of filter(Example 
> REDFISH_MESSAGE_ID) while logging in journal logs for all events and 
> figure out the way to monitor the journal logs without impacting the 
> performance, that should be ok as long as match filters are satisfied 
> for Redfish EventService subscriptions and supported Types(Again 
> differs with implementation).
>
> Thanks,
>
> -Appu
>
> On 2/10/2020 1:52 AM, RAJESWARAN THILLAIGOVINDAN wrote:
>> ApparaRao.
>>
>> As you have shown interest in this feature and submitted the design 
>> document, do you have any opinion on this? Do you see any merit in 
>> using D-Bus match in bmcweb to create event logs for life cycle 
>> events?  Please feel free to weigh in.
>>
>> Thanks,
>> Rajes
>>
>> On 01-02-2020 02:23, 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. For 
>>> life cycle events(ResourceAdded, ResourceRemoved, ResourceUpdated),  
>>> using D-Bus match, bmcweb can create an event log. This requires a 
>>> JSON dictionary, comprising an array of Redfish Resource Name and 
>>> the D-Bus path. This approach works only in case of one to one 
>>> mapping of Redfish Resource Name and the D-Bus path. For 
>>> propertiesChanged events, if the Redfish Resource property is not on 
>>> the same D-Bus path or the Redfish Resource property name is 
>>> different from the D-Bus property name, then an additional JSON 
>>> dictionary to maintain this information is required. With D-Bus 
>>> match alone in the bmcweb, Redfish EventService can't be fully 
>>> supported. For the Message Registers and the Resource Types that are 
>>> supported, the relevant OpenBMC application must create an event log 
>>> in the journal using either the phosphor::logging::entry or 
>>> sd_journal_send() command.
>>>
>>> After realizing that with D-Bus match in the bmcweb alone can't help 
>>> to fully implement EventService, I prefer to avoid using D-Bus match 
>>> in bmcweb. Instead, I prefer to modify the OpenBMC application that 
>>> generated the event to create an event log in the journal. Do you 
>>> see any advantage of using combination of D-Bus match in the bmcweb 
>>> wherever it is possible and changes to OpenBMC application in other 
>>> cases to create an event log ?
>>>
>>> Your views are highly appreciated.
>>>
>>> Thanks,
>>> Rajes
>>
Thanks
Ratan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200224/fda5a477/attachment-0001.htm>