Redfish EventService Implementation

[Ratan Gupta]

Hi James,

As you asked for the examples in the 
thread(https://lists.ozlabs.org/pipermail/openbmc/2020-June/022125.html), 
I have created the mapping at the following location.

https://gist.github.com/ratagupt/0aa4da098a60d49af90a7e4a6ea6d5f2

1) Map1: Mapping between redfish resources to Dbus resources
2) Map2: Mapping between redfish resource types to the ineterested Dbus 
interfaces
3) Map3: Mapping between Dbus resources to redfish resources


I tried to cover the following scenario in the above mapping.

* Redfish resource is mapped to multiple Dbus Resources
* Redfish Property is mapped to single Dbus property
* Redfish Property(complex property) is mapped to multiple dbus property.
* Same type of Redfish Resources are mapped to different Dbus Resources
* Redfish node url having multiple regex : Yet to take a look on this.


Flow would be like as below

=> In bmcweb each Redfish node represents to a Redfish Resource.
=> Each node will be having it's own mapping between Redfish properties 
and the Dbus Resources.

=> Some code on bmcweb will walkthrough on each node during startup , 
get this mapping from each node and generate
    two mappings
    1) Reverse mapping (Dbus Resource to Redfish Resource)(MAP3) and
    2) mapping between Resource Types to the interested Dbus 
interfaces(MAP2)

=> To start with we will support few resource types and then scale it up 
as needed.

=> Map2 would be used when the Redfish client subscribe for the 
ResourceType to get the Dbus mappings.

=> Map3 would be used when the Dbus signal gets generated and need the 
Redfish mappings.

=> Once we have all thsese mapping gets generated and loaded into the 
memory, bmcweb would start listening
    for the interfaces listed in map2.

=> Once any Dbus signal gets generated map3 would be used to get the 
Redfish mapping.

Please let me know if you have any concerns with this approach.

Ratan

On 7/7/20 3:00 AM, Bills, Jason M wrote:
>
>
> 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
>>>>