<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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>
  </body>
</html>