<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Rajes,</p>
    <p>   The dictionary to map Redfish resourceType and D-Bus object
      path( I believe URI intern) is good. It will be great if you share
      design document, if its done. <br>
    </p>
    <p>At the moment, redfish event logs file(/var/log/redfish) doesn't
      have ResourceTypes and OriginResource fields. The Existing redfish
      event log implementation(log service) also doesn't have support
      for that. You can propose design change for same along with how it
      is used in event log service. Same thing, can be adopted to
      EventService, once its agreed by OEM's( I am thinking, it should
      go under new OEM specific compiler flag. But that we can ratify
      later).</p>
    <p>Thanks,</p>
    <p>-Appu<br>
    </p>
    <div class="moz-cite-prefix">On 5/27/2020 5:20 PM, RAJESWARAN
      THILLAIGOVINDAN wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:deed2104-2703-4dd8-8180-f9c4f8fffaee@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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>
    </blockquote>
  </body>
</html>