Redfish EventService Implementation

[Ratan Gupta]

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.

>> 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/20200619/71fe9341/attachment.htm>