From: Sui Chen <suichen@google.com>
To: Vijay Khemka <vijaykhemka@fb.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Request to create repository google-ipmi-bmc-health
Date: Tue, 6 Oct 2020 15:57:30 -0700 [thread overview]
Message-ID: <CAJOps0tR5t4sJQX0-fhBJuKJSnQZJm12gWV9S0OYv4xWU7uzKQ@mail.gmail.com> (raw)
In-Reply-To: <EF663847-4E98-4AC2-8A8C-E37B853C131F@fb.com>
On Fri, Oct 2, 2020 at 1:54 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> Hi Sui,
>
> On 10/1/20, 6:52 PM, "Sui Chen" <suichen@google.com> wrote:
>
> Hi Vijay,
>
> We can use whatever means that gets health monitoring done.
> I have the following questions on how to merge the proposed IPMI
> Blob-based implementation, google-ipmi-bmc-health (referred to as
> "IPMI health blob") with phosphor-health-monitor. The intent of having
> a separate "google-ipmi-bmc-health" was to avoid these questions:
>
> 1) The IPMI health blob is a library, not a daemon, so after the IPMI
> health blob is added, phosphor-health-monitor will have both a library
> and a daemon. The user needs to have a way to configure it. What is
> the recommended way of doing this configuration?
>
> Yes the same repo can generate library as well as daemon. Currently it is
> configuring 2 metrics cpu and memory, we can add another entry like
> IPMI blob and if it is there then only it will build ipmi blobs.
>
> 2) We are sending a protocol buffer through the IPMI interface to the
> BMC, and the protocol buffer may be only used for the IPMI path and
> not anywhere else. Would there be any concerns on the usage of a
> protocol buffer here?
>
> If I understand correctly, protocol buffer will be used by daemon who
> Is responding to the IPMI request and connecting to this daemon via
> library call, then it is completely restricted for the use of protocol buffer.
> If you are passing protocol buffer to this daemon then we have to define
> some policy here.
The Protocol buffer is only for serializing the data to be sent
outside of the BMC. It is not used for communication inside
phosphor-health-monitor and will not be passed to the daemon.
>
> Other than these two things I think adding new metrics to
> phosphor-health-monitor should be manageable. I can start by trying to
> add the IPMI blob handler to phosphor-health-monitor; my first attempt
> might not look very elegant, but if we find answers to the two
> questions above, the merged result will look a lot better. Hopefully
> we can find a solution that works well for everyone.
>
> I am looking forward to your patches
Please check out this WIP:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-health-monitor/+/37092
This WIP currently just adds the IPMI blob-based code to
phosphor-health-monitor almost as-is.
It also shows what we already have now.
There will be some work to merge the daemon and the blob handler in an
organic way, and I am open to discussion with you how to do that. The
first step I think I can do is to put the code for extracting the
metrics (metrics.cpp, blob/metric.cpp) into a single file and share
that between the daemon and the IPMI blob handler.
Another issue I found is I am not using the latest sdbusplus so I have
to comment out the usage of ValueIface::Unit::Percent for now.
To build this requires 1) adding a pkgconfig file to
phosphor-ipmi-blobs (before
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-ipmi-blobs/+/37133
gets merged) and 2) adding phosphor-ipmi-blobs and protobuf to DEPENDS
in phosphor-health-monitor's Bitbake recipe.
Hope this WIP change illustrates our intention clearly.
Thanks!
next prev parent reply other threads:[~2020-10-06 22:59 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 [this message]
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
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=CAJOps0tR5t4sJQX0-fhBJuKJSnQZJm12gWV9S0OYv4xWU7uzKQ@mail.gmail.com \
--to=suichen@google.com \
--cc=openbmc@lists.ozlabs.org \
--cc=vijaykhemka@fb.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).