openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).