Redfish EventService Implementation

[Ratan Gupta]

On 6/29/20 9:03 PM, Bills, Jason M wrote:
>
>
> On 6/29/2020 1:07 AM, Ratan Gupta wrote:
>>
>> On 6/26/20 12:25 AM, Bills, Jason M wrote:
>>>
>>>
>>> On 6/25/2020 10:26 AM, Brad Bishop wrote:
>>>> One idea floating around to address these is inventing a journal
>>>> metadata scheme that is management interface agnostic.  I 
>>>> understand the
>>>> motivation behind that - it is much simpler for an application to 
>>>> slide
>>>> a single journal entry into the journal with all the metadata 
>>>> needed to
>>>> generate events, than it is for an application to snoop multiple 
>>>> signals
>>>> off dbus and pull events out of that.
>>>>
>>>> But I wonder if inventing a management interface agnostic scheme for
>>>> adding events to the journal is really just inventing a new data model
>>>> for how we represent things in a server - e.g. are we just working
>>>> around our dbus data model?  Maybe we should fix it instead, so 
>>>> that it
>>>> isn't so difficult for applications to use it?  With that said I don't
>>>> know how to do this and I could use more concrete details on which 
>>>> areas
>>>> of the data model make it hard to consume signals.  Does anyone 
>>>> have any
>>>> ideas or examples?
>>>>
>>>
>>> On this, I think we may want to separate logging vs. eventing both 
>>> in this feature discussion and in the tools we want to use.
>>>
>>> When we were talking about logging, I think the journal made sense 
>>> since it is designed for logging and has benefits around that usage. 
>>> However, I agree that it doesn't seem like the right tool for 
>>> sending and receiving events and signals and that D-Bus sounds like 
>>> the right tool for that.
>>>
>>> I think I'm still a little confused at the scope.  My understanding 
>>> was that this initial design for EventService was only for 
>>> monitoring event messages and not resources in general. It seems 
>>> like it may not make sense to try to use the same tools and approach 
>>> for both message monitoring and resource monitoring? Do we need to 
>>> treat them separately for now to simplify the discussion?
>> Jason, When you say event messages? What do you mean, Do you mean to 
>> say "/redfish/v1/Systems/system/Logservices/eventlog"? >
>> If yes then this should also go as Resource Event, When ever any log 
>> entry gets created under System Log 
>> (/redfish/v1/Systems/system/Logservices/eventlog/entries), BMC would 
>> notify to the Redfish client saying that "ResourceCreated" with the 
>> URL of the Resource.
> Yes, new entries under 
> "/redfish/v1/Systems/system/Logservices/eventlog", but I thought you 
> could register for specific MessageIDs, so it's not just a generic 
> "new resource" event like others would be.

Can we register for MessageID? I thought client can register for whole 
registry not a specific Message ID.

>
>
>>
>> After receiving this event Redfish client will do a GET request on 
>> the URL(retrieved as part of event) to get the content of the log.
>>
>> This will become generic infra for all types of events.
> What I'm saying is I don't know if there is a good generic solution to 
> cover both the EventLog and all other resources.  I believe the 
> current EventService implementation was designed only for EventLog and 
> may not work well for generic resource events.

Can you get me the example payload for EventLog which is going to be 
sent with the current design? I am not sure how the eventlog and other 
resources are different.

For eventLogs also we have the associated D-bus 
objects(/xyz/openbmc_project/logging,/xyz/openbmc_project/dump etc)

>
>>
>> I would be coming up with few design approaches and downside with 
>> each approach to take it to conclusion.
> Thanks!  What I'm proposing is that we clarify or possibly separate 
> the discussions about EventLog vs. generic resources to avoid 
> confusion and come up with the right solutions for each.
>
>>
>> Ratan
>>