Request to create repository google-ipmi-bmc-health

[Patrick Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201111/c241fa29/attachment.sig>