Redfish EventService Implementation

Tue May 26 22:20:04 AEST 2020

Apparao,

I see that you have uploaded a 
patch(https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/32441) for 
supporting server sent events. This patch supports event filtering based 
on registry prefix  and/or messageId.

I would like to know if you have any plan to support event filtering 
based on resource type. If so, I would like to work together for a 
better solution. Earlier, I have proposed a solution based on D-Bus 
match using a dictionary. With that approach, the major challenge is to 
map Redfish resource and properties to D-Bus object and properties 
respectively.   If D-Bus applications are modified to include resource 
type and origin of condition in the event, then there is no need for a 
map. But,that brings Redfish terminology to the application. Also, this 
will become an overhead if an OEM is not interested in Redfish event 
service.

Thanks,
Rajes
On 25-02-2020 19:36, Puli, Apparao wrote:
>
> Hi Ratan,
>
>    Comments in-line
>
> On 2/24/2020 12:07 PM, Ratan Gupta wrote:
>>
>> 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)
>>
> Currently in logServices( logEntry),  we are not reporting the 
> "OriginOfCondition" property as per schema. I will check with Jason( 
> Who wrote the logService) and get back on this.
>
> BTW can you give me how this information is fetched in IBM way of 
> LogService implementation( D-Bus)? If you already ratified any such, i 
> think we can leverage.  If not, We work together for solution.
>
>>       * Any plan to add resource path in this journal message which
>>         tells that this is the path for which resource created event
>>         generated.
>>
> Same as above.
>>
>>       * Would the path be "Redfish Path/ D-bus Path"?
>>
> As per Redfish specification, This should be "@odata.id" which means 
> it should be of resource uri and so we can't use d-bus path here for 
> OriginOfConditions.
>>
>>       * 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.
>
> Having separate process only for this mapping may not be good( No 
> different from maintaining that map inside bmcweb as there won't be 
> any other consumers). Ideal way is, that should be mapped while 
> logging logEntry's itself. But we are not doing it currently which 
> need to be re-looked. Give me some time, I will think and check with 
> other folks and get back.
>
>> *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.
> Initially i thought "ResourceType" based event filtering can be done 
> using minimal mapping( Using MessageID and args). But that will work 
> for minimal set. If the supported ResourceTypes grows, we will have 
> bigger challenges which i can sense it now.  Anyway, Supported 
> Resources are completely implementation specific. If this value is 
> empty means, by default all event logs will be sent to subscribers. 
> This is what we can start with before supported ResourceTypes list grows.
>>>
>>> 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/20200526/19b4d0c1/attachment.htm>