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

[Chandramohan]

Dear Patrick Williams and Ed Tanous ,



I hope this message finds you well. I wanted to bring to your attention
some observations regarding the use of Redfish in various repositories in
upstream.



   1. After going through couple of repositories, I discovered that many
   upstream repositories are already incorporating Redfish. This is achieved
   either through journald or by directly calling the phosphor-logging API to
   log Redfish-specific metadata. The details of this implementation can be
   found here: link to the implementation
   <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrok.openbmc.org%2Fsearch%3Ffull%3DREDFISH_MESSAGE_ID%26defs%3D%26refs%3D%26path%3D%26hist%3D%26type%3D%26xrd%3D%26nn%3D1%26searchall%3Dtrue&data=05%7C01%7Ccharkude%40nvidia.com%7Ca864c52919e844382cc008dbf5680a7b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638373599440698496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EjE4DlGunhXXsyQYjeU8%2BVqZRzAGkZRr65MDz2pnNTA%3D&reserved=0>.
   Additionally, this approach is documented in upstream design, available
   at link to design documentation
   <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fdocs%2Fblob%2Fmaster%2Farchitecture%2Fredfish-logging-in-bmcweb.md&data=05%7C01%7Ccharkude%40nvidia.com%7Ca864c52919e844382cc008dbf5680a7b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638373599440698496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UtZcUrUm9lC3JSg8b3LLsYWY9BBmbKeHzLn3J%2BXtR0Q%3D&reserved=0>
   .
   2.   As we observe these repositories, it has become apparent that they
   possess limited knowledge of Redfish, focusing primarily on essential
   elements like REDFISH_MESSAGE_ID and REDFISH_MESSAGE_ARGS. I would
   appreciate your insights on whether this approach is considered an
   anti-pattern or if there are potential drawbacks associated with this
   minimalistic understanding of Redfish.


   1. Currently, our solution is similar; the key distinction lies in our
   utilization of D-Bus instead of the journal to log Redfish-specific data.
   2. Furthermore, we are planning to abstract metadata such as message
   registry, message arguments and the origin of conditions. This will involve
   creating a new API that is based on generic (non-Redfish specific)
   concepts, within Phosphor Logging dedicated to generating logs with
   Redfish-specific data on the D-Bus. I previously discussed this proposal in
   more detail in my email from November 2023, which you can find here
   <https://lists.ozlabs.org/pipermail/openbmc/2023-November/034470.html>.


Your insights and feedback on this proposal would be greatly appreciated.


Best Regards

Chandramohan



On Fri, Dec 1, 2023 at 11:54 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> On Wed, Nov 29, 2023 at 11:33:30PM +0530, Chandramohan wrote:
> > 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:
>
> I'm not fully grasping what you're trying to solve.  Do you have more
> details on what your use-case is?
>
> Generally we _don't_ want all the repositories to know "Redfish".  If
> what you're proposing is some special Redfish-oriented handling in every
> repository, I don't think this will fly.
>
> For Redfish Events, I suspect someone would need to start a dbus monitor
> in BMC web to observe interesting changes and to turn them into Redfish
> Events inside bmcweb itself.
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20231205/b97e89ae/attachment.htm>