Trigger: make dbus properties writable

This change allows to modify 'Sensors', 'ReportNames' and 'Thresholds'
dbus properties of Trigger interface. They are required by Redfish to
implement PATCH functionality for Trigger schema.

Some backend changes were required to enable this functionality, and as
such few improvements were made for existing code:
- NumericThreshold and DiscreteThreshold now have common implementation
  where it was possible.
- Internal sensor info structure for Trigger is now the same as the one
  used for Report. This resulted in breaking compatibility with previous
  Trigger persistency data.
- Added getInfo / getParams methods for Sensor and Threshold interfaces.
  They are used by Trigger dbus getters and persistency mechanism now,
  instead of storing this data in Trigger object.

Testing done:
- Unit tests were expanded and are passing
- dbus setters for Sensors and Thresholds are working and modifications
  are reflected by calling appropriate getters.

Signed-off-by: Szymon Dompke <szymon.dompke@intel.com>
Change-Id: I7a14c15a30d78ce872342b5f938aba43c77be9c0
43 files changed
tree: eb31687de09f641183d30701b0368a9cfd2ab28e
  1. redfish-tests/
  2. scripts/
  3. src/
  4. subprojects/
  5. tests/
  6. .clang-format
  7. .gitignore
  8. LICENSE
  9. MAINTAINERS
  10. meson.build
  11. meson_options.txt
  12. OWNERS
  13. README.md
  14. 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