Mapping standard D-Bus sensors to ProcessorMetrics (and other specific schemas)

[Ed Tanous]

On Wed, Apr 7, 2021 at 5:26 AM Ambrozewicz, Adrian
<adrian.ambrozewicz at linux.intel.com> wrote:
>
> Hi,
>
> Currently bmcweb exposes sensors as part of Chassis subnodes in Sensors,
> Power and Thermal schemas. All of them lists sensors as arrays of
> generic properties distinguished by Id/Name etc. On the other hand - for
> well-defined metrics Redfish specifies concrete schemas like
> ProcessorMetrics and MemoryMetrics. They define designated Redfish
> properties with given name and value type.
>
> I'm starting to explore ways to implement these schemas in bmcweb, while
> retaining interoperability with TelemetryService. This requirement
> implicates, that source of these properties should implement
> xyz.openbmc_project.Sensor.Value interface and comply with OpenBMC D-Bus
> sensors architecture, which enforces predefined paths and units for
> various types of sensors.
>
> Question of extending xyz.openbmc_project.Sensor.Value interface (so it
> allows for more types or nested paths, if necessary) is something  I
> know should be considered, but seems like more or less straightforward
> to address.

I'm not following this statement.  From my perspective, this is
something we've already solved at a dbus level.  To attach a "sensor"
to a given inventory item, set up the association back to said
inventory item.  Today, we only connect things to Redfish "Chassis",
because that's currently the only node with sensors, but that's
certainly easy to change and there's nothing about the API that
prevents doing that.

Beyond that, because MemoryMetrics and ProcessorMetrics schemas call
out specific sensor names, I suspect we need to come up with a well
defined set of names;  If you want to populate MemoryMetrics, you
would expose sensors, with associations back to the dimm in question,
and have a sensor called, say,
/xyz/openbmc_project/remaining_block_percentage, and map that to the
RemainingSpareBlockPercentage property.

>
> There is bigger issue I see now - mapping D-Bus sensors to concrete
> Redfish properties. Mapping sensors at inventory level is sorted out
> with use of xyz.openbmc_project.Association.Definitions interface.
> However - I don't see (or know of) any method to link given D-Bus sensor
> with it's designated place in Redfish schema.

This is by design.  Dbus should largely have no reliance on any
specific protocol, and we shouldn't be building interfaces that
require daemons pushing data on the bus to have any knowledge of
Redfish, IPMI, PLDM, or protocol of next year.  This generally means
that some dbus->redfish transforms are not as efficient or clean as
they could be, but it keeps that logic quarantined into bmcweb.  I
suspect bmcweb will need logic to translate redfish URI + property
name to dbus path, and this logic will be non-trivial.

> I've done some PoC implementation of ProcessorMetrics, which relies on
> new D-Bus interface with 'Mapping' property (eg. 'TemperatureCelsius' or
> 'CoreMetrics/12/UnhaltedCycles'). ProcessorMetrics node implementation
> queries D-Bus for all sensors associated with given CPU and populates
> properties if proper mapping was found.

Do you have a pointer to it?  It'd be good to see the code you're thinking of.

With that said, I would be against this approach.  This would require
clients to hardcode in, say, BlocksWritten, as a mapping, which means
that as we have more than just redfish, now each client needs to
hardcode the Redfish representation, the PLDM representation, and the
IPMI representation of the same data.  That seems messy.

>
> Is my PoC approach described above feasible for OpenBMC? What are your
> thoughts? I would like to start a discussion and hear your proposals
> about possible alternatives.
>
> Regards,
> Adrian