<div dir="ltr"><div><font face="georgia, serif">H All,</font></div><div><font face="georgia, serif"><br>I wanted to discuss various design approaches for, sending RF events from various OpenBMC services for resource create/delete/modify cases (but not limited to this), <br>Please find the details below:<br><br>1) Addition of a new API in Phosphor Logging dedicated to generating logs with RF-specific data on the D-bus:<br><br>        Workflow:       <br>        - The caller initiates a call to this API, creating a log entry on the D-bus.<br>        - The new API allows only RF specific data to log using internal D-Bus API from phosphor-logging.<br>        - bmcweb monitors the interface-added signal on the phosphor-logging D-bus logs.<br>        - Transmit the RF event associated with the logs relevant to RF.<br>        (New API details are provided at the end of email)<br>         <br>        Pros:         <br>        Consolidation of all RF-specific components within the logging API rather than being scattered across other repositories.<br><br>        Cons:         <br>        Introduction of an additional API in phosphor-logging for logging RF-related entries.<br><br>2) Utilization of Journal Log to record RF-specific details in the journal, following the approach outlined in <a href="https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md">https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md</a>.<br>        This methodology appears to be adhered to in upstream repositories, as evidenced by references such as:<br>        <a href="https://grok.openbmc.org/xref/openbmc/estoraged/src/estoraged.cpp?r=ff1b64f0#160">https://grok.openbmc.org/xref/openbmc/estoraged/src/estoraged.cpp?r=ff1b64f0#160</a><br>        <a href="https://grok.openbmc.org/xref/openbmc/dbus-sensors/src/TachSensor.hpp?r=1f978631#105">https://grok.openbmc.org/xref/openbmc/dbus-sensors/src/TachSensor.hpp?r=1f978631#105</a><br>        <a href="https://grok.openbmc.org/xref/openbmc/telemetry/src/trigger_actions.cpp?r=cff70c14#94">https://grok.openbmc.org/xref/openbmc/telemetry/src/trigger_actions.cpp?r=cff70c14#94</a><br><br>        Workflow:<br>         <br>        - The caller logs RF-specific details directly from the openBMC repo’s.<br>        - bmcweb (inotify) potentially monitors logs containing RF-specific information (e.g., REDFISH_MESSAGE_ID).<br>        - Transmit the RF event associated with the logs relevant to RF.<br>         <br>        Cons: RF specific stuff scattered across the repos.<br><br>3) Use 'Create'  API from PDI <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Logging/Create.interface.yaml#L7">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Logging/Create.interface.yaml#L7</a> <br>      for generating  RF specific data on D-Bus from backend-repos.<br><br>        Workflow:<br>        - The caller logs RF-specific details using 'Create' API from the openBMC repos<br>        - bmcweb potentially monitors logs containing RF-specific information (e.g., REDFISH_MESSAGE_ID REDFISH_MESSAGE_ARGS ).<br>        - Transmit the RF event associated with the logs relevant to RF.<br>        <br>        Cons: RF specific stuff scattered across the repos.<br>        <br>4) Open to Suggestions:<br>    We remain open to alternative approaches for event transmission. If you have any suggestions or insights, please feel free to share with us.<br>Thank you for your attention to this matter.<br><br>Best Regards<br>Chandramohan Harkude.<br><br>API details in short.<br>Example usage of  new API '</font><span style="font-family:georgia,serif">generateLog' </span><span style="font-family:georgia,serif"> from  phosphor-logging</span><span style="font-family:georgia,serif"> library.</span></div><div><font face="georgia, serif"><br>1)phosphor-user-manager want to send an event when new user is created<br>    Here propertyName and propertyValue is not required therefore dbusPropertyValueList  is empty <br>    std::string dbusPropertyValueList {};<br>    std::string dbusObjectPath = "/xyz/openbmc_project/user/testuser";<br>    generateLog(connObject, MESSAGE_TYPE::RESOURCE_CREATED, Entry::Level::Informational, dbusPropertyValueList , dbusObjectPath);<br><br>2)phosphor-user-manager want to send an event when user is enabled<br>    Here propertyName is 'UserEnabled' and propertyValue is 'true'<br>    std::string dbusPropertyValueList  = "UserEnabled" + ',' + "true";<br>    std::string dbusObjectPath = "/xyz/openbmc_project/user/testuser";<br>    generateLog(</font>

<span style="font-family:georgia,serif">connObject</span><font face="georgia, serif">, MESSAGE_TYPE::PROPERTY_VALUE_MODIFIED,Entry::Level::Alert, dbusPropertyValueList ,dbusObjectPath);<br>    <br>The API 'generateLog' creates entry on the D-Bus using internal D-Bus API from phosphor-logging.<br><br>Note : connObject is boost::asio::connection type</font><br></div></div>