<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Apparao,</p>
<p>Thanks a lot for your suggestions. We lean towards using a
dictionary to map Redfish ResourceType to D-Bus objects path and
vice versa and then using D-Bus match to generate life cycle
events. This way, the changes are limited to bmcweb. The resource
type and the origin resource URI will be included in the event
log. This requires change in the format of event log file
/var/log/redfish. I have commented the same in the server sent
event patch that you have uploaded. Kindly see if you can leave
the parsing of file to the OEMs. That way, the existing
infrastructure can be used by the OEMs to support other filtering
mechanisms as defined in the specification.</p>
Thanks,<br>
Rajes<br>
<p> <br>
</p>
<div class="moz-cite-prefix">On 27-05-2020 09:18, Puli, Apparao
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ea71f5a6-1e63-9e04-f0ab-edbbce1ec162@linux.intel.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Rajeswaran,</p>
<p> Thanks for your mail. At the moment, I don't have plans to
support the "ResourceTypes", "OriginResources" based filtering.
Basically Intel uses file systems based redfish event logs(
journalctl -> rsync-> filesystem) and doesn't use D-Bus
mechanism like IBM uses. So I am not much familiar with D-Bus
logging but some of the suggestions:</p>
<p> 1) While logging redfish events over D-Bus itself, it can
provide details on ResourceTypes and OriginResource URI/Path. <br>
</p>
<p> This is ideal and most efficient way. Since we walked a
walked long distance from start, Its hard to modify all the
services to uses these 2 new input parameters while logging
events( Requires change in almost all repo's)<br>
</p>
<p>2) For resourcesTypes: Can have mapping dictionary against all
MessageId's. For OriginResources: I believe, event log over
D-Bus is already holding the Path. If so, last 3/4 nodes of uri
can be taken and mapped against the resources and that can be
used in Event filtering. We did used same mechanism in case of
telemetry while mapping MetricReportDefinitions to URI.</p>
<p>Hope this helps.</p>
<p>Thanks,</p>
<p>-Appu <br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/26/2020 5:50 PM, RAJESWARAN
THILLAIGOVINDAN wrote:<br>
</div>
<blockquote type="cite"
cite="mid:23e93766-980b-2bd1-fc8c-bb5c18b962eb@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Apparao, <br>
</p>
<p>I see that you have uploaded a patch(<a
class="moz-txt-link-freetext"
href="https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/32441"
moz-do-not-send="true">https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/32441</a>)
for supporting server sent events. This patch supports event
filtering based on registry prefix and/or messageId. <br>
</p>
<p>I would like to know if you have any plan to support event
filtering based on resource type. If so, I would like to work
together for a better solution. Earlier, I have proposed a
solution based on D-Bus match using a dictionary. With that
approach, the major challenge is to map Redfish resource and
properties to D-Bus object and properties respectively. If
D-Bus applications are modified to include resource type and
origin of condition in the event, then there is no need for a
map. But,that brings Redfish terminology to the application.
Also, this will become an overhead if an OEM is not interested
in Redfish event service. <br>
</p>
Thanks,<br>
Rajes<br>
<div class="moz-cite-prefix">On 25-02-2020 19:36, Puli, Apparao
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d27f94a5-7195-422a-9442-9e5e3e0aaae7@linux.intel.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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">
<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>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>