commit | 878442985f67fc07d337200536d17567f62c2007 | [log] [tgz] |
---|---|---|
author | Tomáš Pecka <tomas.pecka@cesnet.cz> | Tue Jan 30 15:20:21 2024 +0100 |
committer | Tomáš Pecka <tomas.pecka@cesnet.cz> | Tue Jan 30 15:37:45 2024 +0100 |
tree | ac28bfdf5d86d1aafadc698a8249aa7b9744c101 | |
parent | 2848fd0bd0455c749b8e93777b2fc06f1445f385 [diff] |
hardware: push multiple alarm-inventory resources at once So far we were pushing to sysrepo each alarm-inventory change separately. Unfortunately this is a computing intensive operations for large data so we have to optimise it a bit. This patch modified the class talking to sysrepo about hardware changes. It now "caches" modifications of resources for an alarm and then pushes them at once. There is still a space for a small improvement: After this patch we create one edit per alarm. This basically gets us with 4 calls (we have 4 alarms) for any change. I think this can be merged into one. I don't think it is worth doing it now (the alarm-inventory does not change that much for hardware related alarms). But of course, I can be wrong. I had to make some testing changes: all component paths were wrapped by the COMPONENT macro inside another macro. Now we push more resources at once and I don't know how to basically call a map function on __VA_ARGS__ so I am wrapping all the components with COMPONENT manually inside any macro call. Change-Id: I9a77dde04e72011a25d6f6e7539fb9b81269e933
Together with sysrepo, this software provides "general system management" of embedded devices. The target platform is anything that runs Linux with systemd. This runs in production on CzechLight SDN DWDM devices.
This component tracks the overal health state of the system, including various sensors, or the state of systemd
units. As an operator-friendly LED at the front panel of the appliance shows the aggregated health state.
Firmware can be updated via RAUC, and various aspects of the system's configuration can be adjusted. This includes a firewall, basic network settings, and authentication management.
For a full list, consult the yang/
directory in this repository.
ietf-access-control-list
, RFC 8519 (with deviations)ietf-hardware
, RFC 8348ietf-system
, RFC 7317 (partial support)ietf-interfaces
, RFC 8343 (generating config for systemd-networkd
, with extensions)ietf-routing
, RFC 8349 (see above)czechlight-system
For building, one needs:
1.78
)pkg-config
libnl-route
for talking to the Linux kernellibsystemd
and systemd
at runtimelibyang-cpp
- C++ bindings for libyangsysrepo-cpp
- C++ bindings for sysrepospdlog
- a logging librarysdbus-c++
- C++ library for D-Busfmt
- C++ string formatting librarynlohmann_json
- C++ JSON librarydocopt
for CLI option parsingnft
- the netfilter tooliproute2
- the ip
tool for testingThe build process uses CMake. A quick-and-dirty build with no fancy options can be as simple as mkdir build && cd build && cmake .. && make && make install
.