libyang v3
This is a huge commit which changes a lot of things in the system,
including the boot process and configuration handling. There are also
massive updates all over the stack which have accumulated in the
upstream projects. In no particular order:
- The configuration schema has changed in an incompatible way. That's
due to an update of some drafts related to the ietf-netconf-server
YANG model and its dependencies; as a result, the way how SSH keys and
SSH listening configuration is managed in YANG data is incompatible
with the previous approach, and that means that we *cannot* import the
previous config into sysrepo which already has new YANG modules.
"Solve" that by simply dropping the entire YANG config (!) because we
decided that it's sometimes better to start from scratch. Yay.
- Config migrations now work at the JSON level, not through sysrepo.
There is currently no real "migration" apart from the initial one (the
one that brings the config schema from the implicit/empty "v0" to
"v9"). The TL;DR version is that future migrations will work on an
JSON input, producing some new JSON output, and only after the
migration is done, we push stuff into sysrepo. Also, the migrations
will (likely) not be performed in a sequence, on a cumulative basis,
but it is now a one-shot process with no intermediate steps. This
should hopefully simplify the launching/wrapping code. From the
developer's standpoint, any migration should focus on bringing the
system to the "final state" (v_new), not to v_old + 1.
These migrations will use `jq` heavily. So far, we only have some
"simple" code which merges objects (and arrays!) recursively, courtesy
of Peter Koppstein (https://stackoverflow.com/a/53666584/2245623).
- Some Buildroot options which should have been hardcoded (e.g.,
persisting of OpenSSH server keys) are now unconditional. Once the
czechlight-cfg-fs package is selected, these cannot be disabled.
- We no longer nuke the entire sysrepo SW stack upon a failure. If,
e.g., cla-sysrepo fails, this does not bring the NETCONF server down
anymore, for example. (We might restore the PartOf=... if this proves
to be a problem.)
- There's a bunch of YANG rules which try to make sure that the NETCONF
server is reasonably configured. Previously, we would simply
reprovision the server config at the next boot, now we have nice error
messages at the YANG level already.
- The RESTCONF server has been vastly improved, and some changes all
over that SW stack were made. Also, cleaned up the packaging a bit
(especially those parts which would be a PITA to split into extra
commits due to conflicts everywhere -- sorry).
- Use `jq` patterns for JSON filtering (to make sure that we can provide
an exclusion filter for the crypto material). Also, since we drop
anything but v9 configs now, let's drop the existing migration tests
(there's nothing to test, really).
Change-Id: Id1bb5b9ee66c6deb7a886289e4d768ce3ff7c9b2
Depends-on: https://gerrit.cesnet.cz/plugins/gitiles/github/buildroot/buildroot/+/refs/heads/cesnet/2024-09-06
Depends-on: https://gerrit.cesnet.cz/c/CzechLight/gammarus/+/7570
diff --git a/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service b/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
index b8f5788..4c9418f 100644
--- a/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
+++ b/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
@@ -1,7 +1,7 @@
[Unit]
Description=Persisting persistent sysrepo datastores to /cfg
-After=netopeer2.service cfg.mount czechlight-migrate.service
-Requires=netopeer2.service cfg.mount czechlight-migrate.service
+After=cfg-yang.service
+Requires=cfg-yang.service
[Service]
Type=simple