From: Chandramohan <chandramohan.harkude@gmail.com>
To: openbmc@lists.ozlabs.org
Subject: Suggestions required for sending the RF events in case of change happens on the backend-repos
Date: Thu, 30 Nov 2023 17:54:30 +0530 [thread overview]
Message-ID: <CAAtDDLbuHhY5iX1Hu-hMZOh8p2FLjn6wkWia+1RfY-0=m0UgRw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3985 bytes --]
(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
[-- Attachment #2: Type: text/html, Size: 6626 bytes --]
next reply other threads:[~2023-11-30 23:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 12:24 Chandramohan [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-29 18:03 Suggestions required for sending the RF events in case of change happens on the backend-repos Chandramohan
2023-12-01 18:24 ` Patrick Williams
2023-12-05 8:45 ` Chandramohan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAtDDLbuHhY5iX1Hu-hMZOh8p2FLjn6wkWia+1RfY-0=m0UgRw@mail.gmail.com' \
--to=chandramohan.harkude@gmail.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).