Suggestions required for sending the RF events in case of change happens on the backend-repos

[Chandramohan]

(Sending again, as  previous one didn't show up in the list )

H All,

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),
Please find the details below:

1) Addition of a new API in Phosphor Logging dedicated to generating logs
with RF-specific data on the D-bus:

        Workflow:
        - The caller initiates a call to this API, creating a log entry on
the D-bus.
        - The new API allows only RF specific data to log using internal
D-Bus API from phosphor-logging.
        - bmcweb monitors the interface-added signal on the
phosphor-logging D-bus logs.
        - Transmit the RF event associated with the logs relevant to RF.
        (New API details are provided at the end of email)

        Pros:
        Consolidation of all RF-specific components within the logging API
rather than being scattered across other repositories.

        Cons:
        Introduction of an additional API in phosphor-logging for logging
RF-related entries.

2) Utilization of Journal Log to record RF-specific details in the journal,
following the approach outlined in
https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md
.
        This methodology appears to be adhered to in upstream repositories,
as evidenced by references such as:

https://grok.openbmc.org/xref/openbmc/estoraged/src/estoraged.cpp?r=ff1b64f0#160

https://grok.openbmc.org/xref/openbmc/dbus-sensors/src/TachSensor.hpp?r=1f978631#105

https://grok.openbmc.org/xref/openbmc/telemetry/src/trigger_actions.cpp?r=cff70c14#94

        Workflow:

        - The caller logs RF-specific details directly from the openBMC
repo’s.
        - bmcweb (inotify) potentially monitors logs containing RF-specific
information (e.g., REDFISH_MESSAGE_ID).
        - Transmit the RF event associated with the logs relevant to RF.

        Cons: RF specific stuff scattered across the repos.

3) Use 'Create'  API from PDI
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Logging/Create.interface.yaml#L7
      for generating  RF specific data on D-Bus from backend-repos.

        Workflow:
        - The caller logs RF-specific details using 'Create' API from the
openBMC repos
        - bmcweb potentially monitors logs containing RF-specific
information (e.g., REDFISH_MESSAGE_ID REDFISH_MESSAGE_ARGS ).
        - Transmit the RF event associated with the logs relevant to RF.

        Cons: RF specific stuff scattered across the repos.

4) Open to Suggestions:
    We remain open to alternative approaches for event transmission. If you
have any suggestions or insights, please feel free to share with us.
Thank you for your attention to this matter.

Best Regards
Chandramohan Harkude.

API details in short.
Example usage of  new API 'generateLog'  from  phosphor-logging library.

1)phosphor-user-manager want to send an event when new user is created
    Here propertyName and propertyValue is not required therefore
dbusPropertyValueList  is empty
    std::string dbusPropertyValueList {};
    std::string dbusObjectPath = "/xyz/openbmc_project/user/testuser";
    generateLog(connObject, MESSAGE_TYPE::RESOURCE_CREATED,
Entry::Level::Informational, dbusPropertyValueList , dbusObjectPath);

2)phosphor-user-manager want to send an event when user is enabled
    Here propertyName is 'UserEnabled' and propertyValue is 'true'
    std::string dbusPropertyValueList  = "UserEnabled" + ',' + "true";
    std::string dbusObjectPath = "/xyz/openbmc_project/user/testuser";
    generateLog( connObject,
MESSAGE_TYPE::PROPERTY_VALUE_MODIFIED,Entry::Level::Alert,
dbusPropertyValueList ,dbusObjectPath);

The API 'generateLog' creates entry on the D-Bus using internal D-Bus API
from phosphor-logging.

Note : connObject is boost::asio::connection type
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20231130/de75dd2b/attachment-0001.htm>