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

[Ambrozewicz, Adrian]

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.

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

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