Re: Redfish EventService Implementation

["Bills, Jason M" <jason.m.bills@linux.intel.com>]

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.

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

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