All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: William Kennington <wak@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Vijay Khemka <vijaykhemka@fb.com>, Sui Chen <suichen@google.com>
Subject: Re: Request to create repository google-ipmi-bmc-health
Date: Wed, 11 Nov 2020 06:14:31 -0600	[thread overview]
Message-ID: <20201111121431.GI3614@heinlein> (raw)
In-Reply-To: <CAPnigKn5cRVz3RuK-czkHVo2od1ZLpHCVgRu9q4OET-_nPwrWw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

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@fb.com> wrote:
> > <11/5/20, 3:55 PM, "Sui Chen" <suichen@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-11-11 12:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 15:27 Request to create repository google-ipmi-bmc-health Sui Chen
2020-10-01 19:05 ` Vijay Khemka
2020-10-02  1:52   ` Sui Chen
2020-10-02 20:54     ` Vijay Khemka
2020-10-06 22:57       ` Sui Chen
2020-10-07  1:43         ` Patrick Williams
2020-11-05 23:54           ` Sui Chen
2020-11-11  6:34             ` Vijay Khemka
2020-11-11  6:38               ` William Kennington
2020-11-11 12:14                 ` Patrick Williams [this message]
2020-11-17  0:00                   ` Sui Chen
2020-11-17  1:41                     ` Patrick Williams
2020-11-18  8:48                     ` Vijay Khemka
2020-11-18 23:06                       ` Sui Chen

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=20201111121431.GI3614@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=openbmc@lists.ozlabs.org \
    --cc=suichen@google.com \
    --cc=vijaykhemka@fb.com \
    --cc=wak@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.