Report: Add TriggerIds property

This change is adding TriggerIds property for Report interface. It is an
array of strings, each representing id of trigger which may update given
report Readings property, due to UpdateReport action. This properly is
read-only, but it can be changed in the runtime, when:
- New Trigger is made using AddTrigger dbus method, when ReportId
  argument contains id of given report.
- Trigger is deleted from dbus, and its ReportNames property included id
  of given report.
- ReportNames property of any trigger is updated to include (or not) id
  of given report.

When this property is modified by service, signal will be emitted on
dbus for property change.

When there is existing trigger with id of non-existing report in its
ReportNames property, its id will be added to TriggerIds property of
such report, the moment it is created by user.

Testing done:
- new UTs were made, all UTs are passing.
- manual testing on dbus interface was successful.

Signed-off-by: Szymon Dompke <szymon.dompke@intel.com>
Change-Id: I1c4c94ce751ddaee001e3cadde3ea60aa8e1c224
29 files changed
tree: 28956a2634c50fcc5d4ef77ce93ebabae54825df
  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