RFC: gNMI/OpenConfig telemetry target for OpenBMC

Hi all,

I'd like to gauge interest in adding a gNMI (gRPC Network Management
Interface) / OpenConfig telemetry target to OpenBMC, and get early feedback
on the approach before investing in a formal design review.

Motivation: OpenBMC exposes platform telemetry through Redfish today — the
`openbmc/telemetry` service aggregates D-Bus sensor readings into
MetricReports, and bmcweb presents them via the Redfish TelemetryService
(with optional push over EventService/SSE). That path grew out of the
"Telemetry Streaming from OpenBMC" discussion back in 2019 (
https://lists.ozlabs.org/pipermail/openbmc/2019-October/019058.html); this
proposal builds on it rather than competing with it. Operators running BMCs
at fleet scale increasingly standardize their collection plane on gNMI with
OpenConfig models — a single streaming-telemetry protocol already used
across their networking and, increasingly, their server and accelerator
estate. For those operators a Redfish-only BMC is a second-class telemetry
source: it must be polled per-endpoint rather than streamed, and it doesn't
speak the OpenConfig path/model vocabulary their collectors already
consume. There's no gNMI target in upstream OpenBMC today — and notably,
even Google (which originated gNMI) ships its upstream BMC telemetry as the
Nemora post-daemon and IPMI metric blobs (`google-misc`), not a gNMI face.

The footprint question, up front. I'm aware the usual (and reasonable)
objection to gNMI in OpenBMC is the weight of the gRPC + protobuf
dependency — that's why it isn't already here. The proposal is designed
around that: the entire target, and its gRPC dependency chain, is opt-in
behind a meson feature (default disabled). With the feature off, no gRPC is
pulled and the default image is byte-for-byte unchanged. A BMC only pays
for it if a platform explicitly enables it.

Prior art: gRPC has been proposed in an OpenBMC repo before — a gRPC
transport for `smbios-mdr` (2023, gerrit 65049) built and passed CI, but
was abandoned in late 2025 with the author's note that it "never passed
upstream review." I read that as gRPC changes struggling to attract
reviewer buy-in absent a maintainer champion, more than a hard policy veto
— which is exactly why I'm leading with the footprint contract and gauging
interest here first, rather than just posting patches.

The approach: a second northbound face, not a new telemetry engine. The
target subscribes to the same `openbmc/telemetry` MetricReports over D-Bus
and streams them via gNMI Subscribe (STREAM SAMPLE/ON_CHANGE, POLL, ONCE)
on OpenConfig paths, over mutual-TLS reusing the BMC certificate store.
There's no new sensor-collection path — if a value isn't already on D-Bus,
it isn't exposed. So it's "one source of truth, two northbound faces:
Redfish (pull) and gNMI (streaming push)." For images that don't run the
telemetry aggregator, the bridge can also source directly from
`xyz.openbmc_project.Sensor.Value` objects (the same D-Bus data
`openbmc/telemetry` would aggregate) — MetricReports stays the primary
path; this just avoids a hard dependency on the aggregator being present.

Status: I have a working prototype (C++ / sdbusplus / gRPC) that streams
end-to-end — Capabilities + Subscribe verified with a gNMI client. I've
validated it against an emulated BMC: an AST2600 OpenBMC booted in a
deterministic full-system simulator, with a modeled LM75 temperature sensor
surfacing on D-Bus via phosphor-hwmon; the target runs in-guest, subscribes
to that sensor, and streams it to an in-guest gNMI client as a live
Subscribe (STREAM/SAMPLE) update on the OpenConfig path
/components/component[name=ambient]/state/temperature/instant — a real
sensor value, traced from the modeled device through to the gNMI update, no
synthetic feed. It's a prototype, not production, and hasn't yet run
against a physical BMC. A design write-up in the OpenBMC design-doc format
is in the repo:

  https://github.com/garybeihl/telemetry-gnmi   (docs/DESIGN.md)

What I'm asking:
1. Is there interest in a gNMI northbound upstream, given the
opt-in-footprint framing?
2. Feedback on the feature-gating approach — is "default-disabled meson
feature, image unchanged when off" the right contract, or is even an
optional gRPC dependency a concern?
3. Where should this live — a new repository, and would anyone from the
telemetry subproject be willing to weigh in?
4. Beyond the abandoned `smbios-mdr` gRPC transport, any prior art or
in-flight work I've missed — and whether a well-gated, clearly-scoped
telemetry face could get the reviewer engagement that earlier gRPC work
didn't.

If there's interest, I'll follow up with a formal design-doc review via
gerrit.

Thanks,
Gary Beihl
[email protected]