Request to create repository google-ipmi-bmc-health

Sui Chen suichen at google.com
Tue Nov 17 11:00:47 AEDT 2020


On Wed, Nov 11, 2020 at 4:14 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Tue, Nov 10, 2020 at 10:38:55PM -0800, William Kennington wrote:
> > My 2c... We have plenty of blob handlers that have their own repos to keep
> > maintainership and purposes separate. The phosphor-ipmi-blobs
> > repository intends to provide a framework, not specific implementations.
>
> Thanks William for the background on phosphor-ipmi-blobs intentions.
>
> > On Tue, Nov 10, 2020 at 10:35 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
> > > <11/5/20, 3:55 PM, "Sui Chen" <suichen at google.com> wrote:
> > >     The "health monitoring IPMI Blob Handler" (that the request in the
> > >     first email in this thread was indended for) was a monolithic IPMI
> > >     blob handler; it used to both generate metrics and handle IPMI
> > >     requests.
> > >     In the last month, I had de-coupled these two functions so the IPMI
> > >     blob handler does not generate metrics but reads metrics from the
> > >     daemon in phosphor-health-monitor via DBus. In other words, the
> > > "monolithic"
> > >     handler has now become a thin layer. On the other hand,
> > >     phosphor-health-monitor will have to be significantly modified to
> > >     generate the metrics that are in a different format from what it's
> > >     generating right now, and Vijay and I are working on that. I had
> > > create a chain
> > >     of changes
> > > https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-health-monitor/+/37659
> > >     to illustrate what I intend to do.
> > >     As a result, there comes the question of where the IPMI blob handler
> > >     should live, and it appears I have the following choices:
> > >     1. in phosphor-health-monitor, or
> > >     2. some centralized location, along with many other IPMI blob
> > > handlers, or
> > >     3. as a separate, new repository, or
> > >     4. something else?
>
> Sui,
>
> Now that the design has been separated so that the majority of the
> metric implementation is in p-h-m and the protobuf-ipmi-specific parts
> just do light-weight dbus operations, it seems reasonable to me to
> create a new repository to hold that part.  That part seems fairly
> unique to what Google intends to do and I don't think we should burden
> the maintainers of another repository with that effort.
>
> I don't have a strong opinion on the IPMI blob handlers being all in one
> vs spread out in individual repositories, as long as those repositories
> are light-weight translations from the dbus APIs to the specific IPMI
> blob format.
>
> --
> Patrick Williams

Hello Patrick,

Thanks for your understanding for our request to create a new repository.

Our team had also met last Friday for a discussion on where the
implementation of the blob handler should go, and we also agreed it is
preferable to create a new repository compared to putting its
implementation in phosphor-health-monitor or phosphor-ipmi-blobs.

Now that the IPMI blob handler lives in its own separate repo, it
seems to me that the design does not have to be separated right now;
the new repo could, for now, hold the monolithic IPMI blob handler
where the metric implementation is entirely in the handler.

In the meantime, we will continue to work on the separated design
where the blob handler does light-weight dbus operations against the
daemon, starting from addressing the comments. This might take some
time but we are invested in its design proposal and we are determined
to finish implementing it.

If this plan sounds reasonable, can we request to create the
repository now? If the word "health" in the name is a concern, how
about "google-ipmi-bmc-metrics"?

Thanks!
Sui


More information about the openbmc mailing list