From: Patrick Williams <patrick@stwcx.xyz>
To: Sui Chen <suichen@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Vijay Khemka <vijaykhemka@fb.com>,
William Kennington <wak@google.com>
Subject: Re: Request to create repository google-ipmi-bmc-health
Date: Mon, 16 Nov 2020 19:41:26 -0600 [thread overview]
Message-ID: <20201117014126.GD4495@heinlein> (raw)
In-Reply-To: <CAJOps0vS6+eiZSdL=w6Trb2K_rTj3Rb2TTyp5_n2=_YrjUgH_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]
On Mon, Nov 16, 2020 at 04:00:47PM -0800, Sui Chen wrote:
> On Wed, Nov 11, 2020 at 4:14 AM Patrick Williams <patrick@stwcx.xyz> wrote:
> > 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.
>
> 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.
I don't really agree with going this direction if I understand
correctly. We started this discussion because people felt there were
bits that were useful to others in a more generic repository and bits
that were only useful to Google. Now that we've come to agreement that
the Google-bits belong in a separate repository, why would we go down
the path that all the bits belong in a separate repository where nobody
else can usefully interact with them?
Given some of the code review comments I left in the
phosphor-health-monitor proposal, I'm not sure we've really come to a
consensus on how metrics like this should be handled architecturally.
If you continue doing the Google-specific parts, I think it is going to
be difficult to unravel the design into something that can be globally
applicable.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-11-17 1:43 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
2020-11-17 0:00 ` Sui Chen
2020-11-17 1:41 ` Patrick Williams [this message]
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=20201117014126.GD4495@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.