Redfish EventService Implementation

[Bills, Jason M]

On 7/3/2020 3:15 AM, Ratan Gupta wrote:
>>>> 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.
> 
I don't really know.  I thought that's what the current implementation 
allowed, but I don't know for sure if it can or should.

>>
>>
>>>
>>> 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.
> 
This is based on the assumption that for a LogService, you can register 
for a MessageId.  If this is not possible, then they might be treated 
the same.

> For eventLogs also we have the associated D-bus 
> objects(/xyz/openbmc_project/logging,/xyz/openbmc_project/dump etc)
> 
For Intel platforms, we don't use /xyz/openbmc_project/logging, so we 
don't have D-Bus objects associated with each EventLog LogEntry.  We use 
rsyslog to create a file that contains many LogEntries.

However, as an unrelated side-thought: linking logging to 
/xyz/openbmc_project/dump made me wonder if there is a possible solution 
to the logging issue if we treat /xyz/openbmc_project/logging like 
/xyz/openbmc_project/dump and place a pointer to the log in the D-Bus 
object instead of the log itself?

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