Remove variant from Thresholds interface

The Thresholds property on the Trigger interface is currently defined as
a relatively complex type:
variant<
   array<discrete struct>
   array<numeric struct>
>

This causes some oddities in unpacking given that Dbus properties are
already a variant, applications consuming this interface have to double
wrap the variant.  This was confusing enough that bmcweb has to keep the
trigger types separate, and cannot use the common typing.

This commit changes by adding two new parameters
NumericThresholds: array<numeric struct>
DiscreteThresholds: array<discrete struct>

Which deduplicates the double wrapped variant.

The intent is that this duplicated interface will exist for a transition
period of a week or two, while bmcweb (the only user of this)
transitions the code to use the new properties, then a followup common
will drop the thresholds properly.

Tested: WIP

Change-Id: I6717d4075de53c91aa179a90c7a844c4a13534cc
Signed-off-by: Ed Tanous <ed@tanous.net>
6 files changed
tree: 6fc86a85bebde95aeab8d06de7354b9f91b9798f
  1. redfish-tests/
  2. src/
  3. subprojects/
  4. tests/
  5. .clang-format
  6. .gitignore
  7. gcovr.cfg
  8. LICENSE
  9. meson.build
  10. meson.options
  11. OWNERS
  12. README.md
  13. xyz.openbmc_project.Telemetry.service.in
README.md

Telemetry

This component implements middleware for sensors and metrics aggregation.

Capabilities

This application is implementation of Telemetry proposed in OpenBMC design docs [1].

It's responsible for:

  • on-demand creation of metric reports,
    • aggregated sets of sensor values available in system [2],
  • access to metric report in both pull and push model (triggers),
  • run-time monitoring of sensor[3] updates.

Use-cases

  • generic and centralized way to observe telemetry data inside system
  • back-end for Redfish TelemetryService[4]

How to build

There are two way to build telemetry service:

  • using bitbake in yocto environment
  • using meson as native build

To build it using bitbake follow the guide from OpenBMC docs[5]. To build it using meson follow the quick guide to install meson[6] and then run below commands

meson build
cd build
ninja

After successful build you should be able to run telemetry binary or start unit tests

./tests/telemetry-ut
./telemetry

In case if system is missing boost dependency, it is possible to build it locally and set BOOST_ROOT environment variable to location of built files for meson. After this change meson should be able to detect boost dependency. See [7] for more details.

Notes

More information can be found in OpenBMC docs repository [8].

References

  1. OpenBMC platform telemetry design
  2. Sensor support for OpenBMC
  3. dbus-sensors
  4. Redfish TelemetryService
  5. Yocto-development
  6. Meson-Quick-Guide
  7. Meson-Boost-dependency
  8. OpenBMC-docs-repository