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

[Ambrozewicz, Adrian]

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:
- multiple items (eg. Processors) exposing the same data, names would 
need to be unique in that regard
- certain properties are singular (CPU-wide) while other are buried down 
the hierarchy (mentioned UnhaltedCycles of Core#12).

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?

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

> 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