<div dir="ltr"><div class="gmail-gs" style="margin:0px;padding:0px 0px 20px;width:initial;min-width:0px;font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div class="gmail-"><div id="gmail-:2m2" class="gmail-ii gmail-gt" style="direction:ltr;margin:8px 0px 0px;padding:0px;font-size:0.875rem;overflow-x:hidden"><div id="gmail-:2m1" class="gmail-a3s gmail-aiL" style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif;overflow:auto hidden;direction:initial"><div dir="ltr"><div><font face="georgia, serif">(Sending again, as </font>
<span class="gmail-ui-provider gmail-a gmail-b gmail-c gmail-d gmail-e gmail-f gmail-g gmail-h gmail-i gmail-j gmail-k gmail-l gmail-m gmail-n gmail-o gmail-p gmail-q gmail-r gmail-s gmail-t gmail-u gmail-v gmail-w gmail-x gmail-y gmail-z gmail-ab gmail-ac gmail-ae gmail-af gmail-ag gmail-ah gmail-ai gmail-aj gmail-ak" dir="ltr">previous one didn't show up in the list</span> <font face="georgia, serif">)</font><br></div><div><font face="georgia, serif"><br></font></div><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div></div></div></div></div></div></div>