<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <p>Further to my previous mail, I wanted to see how a JSON
      dictionary would look like for implementing Redfish EventService
      based on D-Bus match. The D-Bus match approach is good for
      implementing life cycle events((ResourceAdded, ResourceRemoved,
      ResourceUpdated). In bmcweb, a Redfish Resource is viewed as
      having a set of properties which comes from one or more D-Bus
      objects. So, when a client subscribes for a ResourceType, using a
      JSON dictionary, find the D-Bus object(s) mapped to the
      ResourceType and create matches. When the D-Bus match occurs,
      again using aJSON dictionary, find the Redfish ResourceType mapped
      to the D-Bus object and create events. The JSON dictionary should
      also provide the Redifsh URI which needs to be specified in the
      event. An example JSON dictionary for mapping the Redifsh
      ResourceTypes LogEntry and ComputerSystem is available here : <a
        moz-do-not-send="true"
href="https://gist.github.com/trajeswaran/fec230abd36181f85d2f20d09164ec05">
https://gist.github.com/trajeswaran/fec230abd36181f85d2f20d09164ec05</a>.
      In case of LogEntry, there is one to one mapping of ResourceType
      to D-Bus object. In case of ComputerSystem, the properties comes
      from multiple D-Bus objects. Do you see any drawback with this
      approach?  Kindly let me know what you think. Thanks in advance. <br>
    </p>
    <p><br>
    </p>
    <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>
  </body>
</html>