<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Ratan,</p>
<p> Comments in-line<br>
</p>
<div class="moz-cite-prefix">On 2/24/2020 12:07 PM, Ratan Gupta
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Apparao,</p>
<div class="moz-cite-prefix">On 2/20/20 12:49 AM, Puli, Apparao
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1a22b091-675c-3e1d-b57a-d44b3ba5d4e0@linux.intel.com">Hi,
<br>
<br>
I am sorry for late response as this mail is buried under and
got struck back of my mind. <br>
<br>
As i did mentioned in EventService design document, EventLog
Monitor service is not common across the organizations( Example:
Intel uses the redfish event logs file and inotify mechanism for
monitoring the event logs. Where as IBM uses d-bus event log
mechanism and they can relay on match rules). That said
challenges with ResourceType mapping will be different in both
monitoring mechanisms. This is good point. Initially when i
started EventService design, i thought we can have mapping in
bmcweb for ResourceTypes with set of MessageID's for Logged
events ( As per Intel design) but not sure that may become
difficult when we expand supported ResourceTypes. <br>
</blockquote>
<p><tt>If I am getting correctly, Here is the flow which Intel
uses.</tt></p>
<ol>
<li><tt>Individual repo have to push the logs using
sd_journal_send which will write to the
file(/var/log/redfish) by using rsyslog daemon</tt></li>
</ol>
<pre><span class="pl-en"> sd_journal_send</span>(<span class="pl-s"><span class="pl-pds">"</span>MESSAGE=%s<span class="pl-pds">"</span></span>, <span class="pl-s"><span class="pl-pds">"</span>journal text<span class="pl-pds">"</span></span>, <span class="pl-s"><span class="pl-pds">"</span>PRIORITY=%i<span class="pl-pds">"</span></span>, <LOG_LEVEL>,
<span class="pl-s"><span class="pl-pds">"</span>REDFISH_MESSAGE_ID=%s<span class="pl-pds">"</span></span>,
<span class="pl-s"><span class="pl-pds">"</span>ResourceEvent.1.0.ResourceCreated<span class="pl-pds">"</span></span>, <span class="pl-c1">NULL</span>);
</pre>
<blockquote>
<ul>
<li> <tt>How you would populate the "</tt><tt><span
class="treeLabel objectLabel" aria-labelledby="default"
data-level="3">OriginOfCondition</span></tt><tt>" during
sending of event? (<a class="moz-txt-link-freetext"
href="https://redfish.dmtf.org/schemas/v1/Event.v1_4_1.json"
moz-do-not-send="true">https://redfish.dmtf.org/schemas/v1/Event.v1_4_1.json</a>)</tt></li>
</ul>
</blockquote>
</blockquote>
<p><tt>Currently in logServices( logEntry), we are not reporting
the "OriginOfCondition" property as per schema. I will check
with Jason( Who wrote the logService) and get back on this.</tt></p>
<p><tt>BTW can you give me how this information is fetched in IBM
way of LogService implementation( D-Bus)? If you already
ratified any such, i think we can leverage. If not, We work
together for solution. <br>
</tt></p>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<blockquote>
<ul>
</ul>
</blockquote>
<blockquote>
<ul>
<li><tt> Any plan to add resource path in this journal message
which tells that this is the path for which resource
created event generated.</tt></li>
</ul>
</blockquote>
</blockquote>
<tt>Same as above.</tt><br>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<blockquote>
<ul>
</ul>
</blockquote>
<blockquote>
<ul>
<li><tt> Would the path be "Redfish Path/ D-bus Path"?</tt></li>
</ul>
</blockquote>
</blockquote>
As per Redfish specification, This should be "@odata.id" which means
it should be of resource uri and so we can't use d-bus path here for
OriginOfConditions.<br>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<blockquote>
<ul>
<li><tt>Where the mapping would be done between
D-busPath/Redfish Resource path?</tt></li>
</ul>
</blockquote>
<pre>
Cons: Every application have to make the change(use sd_journal_send).
My thought is backend application should not be aware of the redfish terminlogy.</pre>
</blockquote>
<p>Having separate process only for this mapping may not be good( No
different from maintaining that map inside bmcweb as there won't
be any other consumers). Ideal way is, that should be mapped while
logging logEntry's itself. But we are not doing it currently which
need to be re-looked. Give me some time, I will think and check
with other folks and get back.<br>
</p>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<pre>
</pre>
<p><tt> <b> 2.</b> Some application(bmcweb) would do the Inotify
on the path(/var/log/redfish) and send the event once there is
any activity on this file.</tt></p>
<pre>> I thought we can have mapping in bmcweb for ResourceTypes with set of MessageID's for Logged events ( As
per Intel design)
Can you explain more here. What is your plan? How you would do the Resource Type based event filtering? <span class="pl-s">REDFISH_MESSAGE_ID is different than the resource type.</span></pre>
</blockquote>
Initially i thought "ResourceType" based event filtering can be done
using minimal mapping( Using MessageID and args). But that will work
for minimal set. If the supported ResourceTypes grows, we will have
bigger challenges which i can sense it now. Anyway, Supported
Resources are completely implementation specific. If this value is
empty means, by default all event logs will be sent to subscribers.
This is what we can start with before supported ResourceTypes list
grows.<br>
<blockquote type="cite"
cite="mid:813853bb-b3a3-79a7-94c5-bbe487c2902b@linux.vnet.ibm.com">
<pre>
<span class="pl-s"><span class="pl-pds"></span></span><span class="pl-s"></span></pre>
<blockquote type="cite"
cite="mid:1a22b091-675c-3e1d-b57a-d44b3ba5d4e0@linux.intel.com">
<br>
As per my reading from below query, You are looking at d-bus
match rules and ResourceTypes mapping which is more specific to
d-bus event logging(IBM way of implementing event logging).
reading it from journal logs will give more information but that
will impact the performance to large extent. This might be one
of the reason why we (Intel) uses Redfish message ID while
logging redfish events logs to journal(You can refer design
document for same at <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>).
In opinion, in your d-bus if you are using some kind of
filter(Example REDFISH_MESSAGE_ID) while logging in journal logs
for all events and figure out the way to monitor the journal
logs without impacting the performance, that should be ok as
long as match filters are satisfied for Redfish EventService
subscriptions and supported Types(Again differs with
implementation). <br>
<br>
Thanks, <br>
<br>
-Appu <br>
<br>
On 2/10/2020 1:52 AM, RAJESWARAN THILLAIGOVINDAN wrote: <br>
<blockquote type="cite">ApparaRao. <br>
<br>
As you have shown interest in this feature and submitted the
design document, do you have any opinion on this? Do you see
any merit in using D-Bus match in bmcweb to create event logs
for life cycle events? Please feel free to weigh in. <br>
<br>
Thanks, <br>
Rajes <br>
<br>
On 01-02-2020 02:23, RAJESWARAN THILLAIGOVINDAN wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
I am going through the bmcweb code for implementing Redfish
EventService based on the design document <a
class="moz-txt-link-freetext"
href="https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749"
moz-do-not-send="true">https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749</a>.
This design is hooked to the journal based Redfish Event
Logging. For life cycle events(ResourceAdded,
ResourceRemoved, ResourceUpdated), using D-Bus match,
bmcweb can create an event log. This requires a JSON
dictionary, comprising an array of Redfish Resource Name and
the D-Bus path. This approach works only in case of one to
one mapping of Redfish Resource Name and the D-Bus path. For
propertiesChanged events, if the Redfish Resource property
is not on the same D-Bus path or the Redfish Resource
property name is different from the D-Bus property name,
then an additional JSON dictionary to maintain this
information is required. With D-Bus match alone in the
bmcweb, Redfish EventService can't be fully supported. For
the Message Registers and the Resource Types that are
supported, the relevant OpenBMC application must create an
event log in the journal using either the
phosphor::logging::entry or sd_journal_send() command. <br>
<br>
After realizing that with D-Bus match in the bmcweb alone
can't help to fully implement EventService, I prefer to
avoid using D-Bus match in bmcweb. Instead, I prefer to
modify the OpenBMC application that generated the event to
create an event log in the journal. Do you see any advantage
of using combination of D-Bus match in the bmcweb wherever
it is possible and changes to OpenBMC application in other
cases to create an event log ? <br>
<br>
Your views are highly appreciated. <br>
<br>
Thanks, <br>
Rajes <br>
</blockquote>
<br>
</blockquote>
</blockquote>
Thanks<br>
Ratan<br>
<p><br>
</p>
</blockquote>
</body>
</html>