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", , >> "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 >> >>