<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<div class="moz-cite-prefix">On 6/19/20 6:56 PM, Ratan Gupta wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fde794a3-58f9-f332-fd3b-3cfcc116f239@linux.vnet.ibm.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p><br>
</p>
<div class="moz-cite-prefix">On 6/18/20 2:15 AM, Patrick Williams
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20200617204516.GE4618@heinlein">
<pre class="moz-quote-pre" wrap="">On Wed, Jun 17, 2020 at 05:38:47PM +0530, Ratan Gupta wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi James,Pattrick.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">My intention was not to re-implement the logging, my intention was to
extend/use the existing design which we already have it below.
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md" moz-do-not-send="true">https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md</a>
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Good. This wasn't clear from the earlier email. Thanks.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">As we are in agreement that we want to use the journal for persistence
and log rotate feature.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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. ]
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">***** 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. ******
</pre>
</blockquote>
</blockquote>
<p><tt>Jaosn: You asked the following query in other thread </tt><tt><i><b>"Why
do we want to log on D-Bus property updates? This seems
like it will be too noisy for the EventLog</b>"</i></tt></p>
<p><tt>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,</tt><tt> To handle this
request the flow would be</tt><br>
</p>
<p><tt>Redfish Client subscribe for "ResourceType" eg:
"EthernetService,AccountService,LogService" with subordinate
resources property as true</tt><tt> </tt><tt>which 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.</tt></p>
<p><tt>Apparo: Please correct me if I am missing something.</tt></p>
<blockquote type="cite" cite="mid:20200617204516.GE4618@heinlein">
<pre class="moz-quote-pre" wrap="">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?</pre>
</blockquote>
<tt><a class="moz-txt-link-freetext"
href="https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749/16/designs/redfish-eventservice.md#474"
moz-do-not-send="true">https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749/16/designs/redfish-eventservice.md#474</a></tt><tt><br>
</tt><tt><br>
</tt><tt>While I am reading the redfish
spec(<a class="moz-txt-link-freetext"
href="https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.11.0.pdf"
moz-do-not-send="true">https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.11.0.pdf</a>)
, it is not clear that the events need to be persisted.</tt><tt>I
will ask in the DMTF for the persistence of the events.</tt><tt><br>
</tt></blockquote>
<tt>I have got an update from the DMTF that persistence is not
required to be implemented for the
events(<a class="moz-txt-link-freetext" href="https://redfish.dmtf.org/schemas/v1/Event.v1_5_0.json">https://redfish.dmtf.org/schemas/v1/Event.v1_5_0.json</a>), <br>
which implies we don't need to log the events in Journal.<br>
<br>
More info(<a class="moz-txt-link-freetext" href="https://github.com/DMTF/Redfish/issues/3646">https://github.com/DMTF/Redfish/issues/3646</a>)<br>
<br>
Now updating the proposal where redfish client subscribed for
Resource Type based events<br>
1) Client would subscribe for the Redfish
Resource(eg:ManagerAccount) to receive events like Account
add/delete/modify <br>
Hence need for mapping from (RedfishResource to Dbus
Resource) <br>
<br>
2) Have the mapping info from Redfish resources to DBUS Resources
(Some JSon file may have this mapping)<br>
<br>
2) Have the reverse mapping from DBUS Resources to Redfish
Resources<br>
* This is needed to send the Redfish event if there is any
changes in the corresponding D-bus resources. <br>
eg BMC state change/network change etc.<br>
<br>
3) bmcweb would monitor the DBUS events<br>
<br>
4) Get the Redfish Path from the Mapping(2) and send the Redfish
event<br>
<br>
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.<br>
<br>
James, Apparao: Please let me know if there is any more concern
with this approach.</tt><br>
<blockquote type="cite"
cite="mid:fde794a3-58f9-f332-fd3b-3cfcc116f239@linux.vnet.ibm.com"><tt>
</tt><br>
<blockquote type="cite" cite="mid:20200617204516.GE4618@heinlein">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">#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.</pre>
</blockquote>
<tt>I would respond on the same once my query gets answered from
DMTF.</tt><br>
<tt>If my query gets answered yes then we have to write on flash
but let's </tt><br>
<tt>wait for it,</tt><br>
<blockquote type="cite" cite="mid:20200617204516.GE4618@heinlein">
</blockquote>
</blockquote>
</body>
</html>