<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Appu,</p>
    <p>Can you get me an example say if I want an redfish event to be
      generated once any local user gets added on the BMC.</p>
    <p>What would be the steps to be done with the current design and
      where(which repo)?</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/28/20 12:28 AM, Puli, Apparao
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fc0c20a9-f132-4dc6-d27a-d6b09b4900d7@linux.intel.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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>
    </blockquote>
    Ratan<br>
  </body>
</html>