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

[Ed Tanous]

On Tue, Apr 27, 2021 at 4:38 AM Ambrozewicz, Adrian
<adrian.ambrozewicz at linux.intel.com> wrote:
>
> W dniu 4/9/2021 o 17:27, Ed Tanous pisze:
> > 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.
> >
> That is correct. Technically we have all the pieces to integrate sensor
> with Redfish in general (Associations, standard sensor types and APIs).
> Challenge lies below.
>
> > 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.
> >
> Is the path you've provided just a shortcut for full D-bus sensor path,
> or do you have something else in mind? I will assume the former.
>
> D-Bus sensor path is composed of :
> /xyz/openbmc_project/{namespace/type}/{name}. Do you propose to encode
> sensor name in such a way, that bmcweb (and IPMI,PLDM, whatever) would
> be able to identify exact meaning of the value if they need to? Bear in
> mind that we have several issues to consider here:

I missed the units in my first email.  That should've read;

xyz/openbmc_project/utilization/remaining_block_percentage

> - multiple items (eg. Processors) exposing the same data, names would
> need to be unique in that regard

This is solved by having an association back to the processor in
question.  Names would need to be unique, but not unique
per-processor, although you bring up a good point.
As I think through this more, I suspect Sensor.Value isn't a good fit
for this kind of data.  I suspect we should come up with some specific
interfaces for exposing this kind of telemetry in a standard way.

> - certain properties are singular (CPU-wide) while other are buried down
> the hierarchy (mentioned UnhaltedCycles of Core#12).

Also solved by associations.  If it's associated with a core, it's the
property for that core, if it's associated with the processor object,
it's a property of that socket.

>
> This would lead to names like:
> /xyz/openbmc_project/sensors/counter/cpu1_core12_unhaltedcycles .
>
> Don't get me wrong - this seems like quite flexible approach, however it
> lacks standardization. If I understood response form Patrick correctly -
> there is urge to avoid storing information in D-Bus path. Do you think
> that would be acceptable to introduce this logic (name-encoding) in bmcweb?

No, having read Patricks email, I agree with him.  What I proposed was
only a strawman, and hadn't been fully thought through.

>
> >>
> >> 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.
> >
> Point taken - mapping data (in whatever form it will be available)
> should be generic and domain agnostic.
>
> >> 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.
> >
> Code itself is boilerplate D-Bus sensor service with one extra property.
> New property contains data encoded in the string, which you already
> proposed to be part of the name. Should you have need to work on some
> shared code to work out PoC in the flesh - let me know.

Text descriptions of code are a lot less useful than code I can look
at and run.  With that said, if you don't want to publish it
somewhere, no worries.

>
> > 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