Redfish EventService Implementation

[Ratan Gupta]

On 6/19/20 6:56 PM, Ratan Gupta wrote:
>
>
> On 6/18/20 2:15 AM, Patrick Williams wrote:
>> On Wed, Jun 17, 2020 at 05:38:47PM +0530, Ratan Gupta wrote:
>>> Hi James,Pattrick.
>>>
>>>>> Can't we do this already today by defining a simple errors/metadata file
>>>>> in phosphor-dbus-interfaces and calling 'logging::report<...>' on it?
>>>>> This will create a record on dbus in phosphor-logging.
>>>>>
>>>> I think the original concern was with supporting on the order of
>>>> 10,000 log entries, having this on d-bus seemed impractical. Also the
>>>> free log rotation the journal provides is useful. Now modifying the
>>>> logging::report<...> to conditionally log to the journal seems realistic.
>>> My intention was not to re-implement the logging, my intention was to
>>> extend/use the existing design which we already have it below.
>>>
>>> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md
>>>
>>> I was trying not to bring the Redfish specific stuff in each individual
>>> repo, instead each transport can listen for
>>> Dbus events and write to the journal which goes to their app specific file.
>> Good.  This wasn't clear from the earlier email.  Thanks.
>>
>>
>>> As we are in agreement that we want to use the journal for persistence
>>> and log rotate feature.
>> I'm not convinced there is agreement on this.  There has been
>> disagreement about even using the journal for phosphor-logging use since
>> the beginning and I suspect there would be less agreement on another
>> application using it as its own IPC mechanism.
>>
>> Just because a hammer can be used to insert a nail into a board doesn't
>> mean you use it insert any pointy thing into a flat thing.  [ Just
>> because the journal provides log rotation and persistance doesn't mean
>> you should use it for every feature needing log rotation and
>> persistance. ]
>>
>>
>>> ***** As per the Redfish one of the requirement is we need the log for
>>> most of the Dbus Property update/interface added as they
>>> are mapped to some Redfish Resource and the bmcweb has to send the
>>> Resource updated/modified signal to the
>>> Redfish client. ******
>
> Jaosn: You asked the following query in other thread /*"Why do we want 
> to log on D-Bus property updates?  This seems like it will be too 
> noisy for the EventLog*"/
>
> Eg: Client is interested for an event when ever there is any user 
> add/delete or network configuration change or there is a log entry 
> resource gets created,To handle this request the flow would be
>
> Redfish Client subscribe for "ResourceType" eg: 
> "EthernetService,AccountService,LogService"  with subordinate 
> resources property as truewhich means the Client is looking for 
> updates on the subscribed resources and the subordinates resource, 
> These redfish resources(EthernetInterface, IP address, ManagerAccount, 
> AccountService) would be mapped to some D-bus Resources, hence some 
> application/bmcweb  would monitor the Dbus signals on the interested 
> Dbus objects and send the Redfish event to the subscribed client.
>
> Apparo: Please correct me if I am missing something.
>
>> I don't know Redfish well, so bear with me if there is something obvious
>> I'm missing.  But, the first part of this "requirement" doesn't seem to
>> follow from the second part of the "requirement" to me.
>>
>> Sending a signal of a property changing to the Redfish clients is
>> straight-forwawrd; Redfish should subscribe to all the appropriate
>> dbus-events.  I don't understand how this implies any sort of logging.
>> Where does the logging part of this requirement come from?
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749/16/designs/redfish-eventservice.md#474
>
> While I am reading the redfish 
> spec(https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.11.0.pdf) 
> , it is not clear that the events need to be persisted.I will ask in 
> the DMTF for the persistence of the events.
I have got an update from the DMTF that persistence is not required to 
be implemented for the 
events(https://redfish.dmtf.org/schemas/v1/Event.v1_5_0.json),
which implies we don't need to log the events in Journal.

More info(https://github.com/DMTF/Redfish/issues/3646)

Now updating the proposal where redfish client subscribed for Resource 
Type based events
1) Client would subscribe for the Redfish Resource(eg:ManagerAccount) to 
receive events like Account add/delete/modify
      Hence need for mapping from (RedfishResource to Dbus Resource)

2) Have the mapping info from Redfish resources to DBUS Resources (Some 
JSon file may have this mapping)

2) Have the reverse mapping from DBUS Resources to Redfish Resources
      * This is needed to send the Redfish event if there is any changes 
in the corresponding D-bus resources.
        eg BMC state change/network change etc.

3) bmcweb would monitor the DBUS events

4) Get the Redfish Path from the Mapping(2) and send the Redfish event

5) Bmcweb would buffer N number of events that can be configurable by 
redfish client. Buffer would get cleaned up in case of bmcweb restart or 
BMC reset.

James, Apparao: Please let me know if there is any more concern with 
this approach.
>
>>> We have two options:
>>>       1) Each transport interface listens for the Dbus signals and write
>>> it to their app specific file.
>>>       2) Each openbmc repo must use log::report for each D-bus property
>>> update/ interface added.
>> #2 is absolutely unworkable on the surface to me.  log::report is to
>> create a error entry (xyz.openbmc_project.Logging.Entry), which creates
>> a dbus-object, which would cause log::report to be called, which creates
>> a dbus-object, which ...
>>
>> Even if what you meant was something like logging::log<info>, this seems
>> pretty heavy.  I'm not sure this is something that can be inserted into
>> sdbusplus, especially for the ASIO-based object servers, because in many
>> cases applications register their own callback.  For the sdbus++
>> generated server bindings we could squeeze it in.  But, what you're
>> proposing here is essentially a "journal-as-dbus-monitor".  We'd
>> certainly need to make some measurements on how many kB/s worth of
>> journal entries this would create because I suspect we could end up
>> burning out a NAND flash with as many writes as that would induce.
> I would respond on the same once my query gets answered from DMTF.
> If my query gets answered yes then we have to write on flash but let's
> wait for it,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200623/3d84eb41/attachment.htm>