Use new, daemon-less sysrepo for YANG management
Updating all dependencies so that we're using the new sysrepo. The easiest way
there was via bringing in the new buildroot as well, which meant:
- new RAUC, hence no patch needed anymore,
- newer systemd, hence an updated patch,
- New spdlog and fmt, which means that the version we ship in
submodules/dependencies no longer works. Fix that by just relying on
systemwide spdlog.
- uboot-tools needed a patch because there's no /var/lock,
- OpenSSH was previously started autmagically, now we're explicitly
adding that to the list of packages (I really like SSH, don't you?).
New sysrepo means that there's no `sysrepod` anymore, which required
changing a bunch of other units so that they are not marked as
`PartOf=sysrepod.service` anymore. Also, the command-line options for
`sysrepocfg` and `sysrepoctl` changed.
I had to patch buildroot so that it doesn't create SSH keys for the
NETCONF server at build time, and that all required modules are actually
installed. It turns out that new sysrepo doesn't really install
anything, and the fun only starts with Netopeer2. Their install scripts
a wee bit picky, but hey, we have bash, we can make it work.
On the other hand, installation of *our* YANG modules is a bit hairy.
There's just too much parallel activities going on, and therefore I have
no idea how robust our callout to `sysrepoctl --apply` really is. As a
cherry on top, `sysrepocfg` is particularly inconsistent when it comes
to how the **** one is supposed to provision the initial config, etc
etc. In the end, I ended up with a big hammer.
Installation of all non-netopeer2 YANG modules now happens from just a
single script, the previous way was very fragile and failed quite often
-- probably because that "wonderful" new way of installing a module and
possibly enabling a feature and also importing some data which might or
might not be the required initial data, so *THAT* thing, depended on
whether there already was or was not another SW connection. Wonderful.
If only there was a oneliner for that, then we could have avoided all
this stupid boilerplate. Oh well.
On the other hand, the `cla-sysrepod` is now properly signalling its
"up-and-running" status to systemd, *and* this up-and-running state is
only reached once the configuration has been propagated to the optical
HW. As a result, the HW watchdog will recover from an upload of a broken
FW (or, alternatively, it will keep rebooting if the optical HW is
FUBAR -- pick your poison, sir).
Change-Id: I4b65a8fb345bfe7907a331d0de16294af1c36a78
diff --git a/package/cla-sysrepo/cla-appliance.service.in b/package/cla-sysrepo/cla-appliance.service.in
index 82d01d2..8058606 100644
--- a/package/cla-sysrepo/cla-appliance.service.in
+++ b/package/cla-sysrepo/cla-appliance.service.in
@@ -1,14 +1,14 @@
[Unit]
Description=CzechLight __MODEL__ driver
-After=syslog.target network.target sysrepod.service
+After=syslog.target network.target czechlight-install-yang.service
Before=rauc-mark-good.service
-Requires=sysrepod.service
-PartOf=sysrepod.service
+PartOf=netopeer2.service
+Requires=czechlight-install-yang.service
StartLimitIntervalSec=0
ConditionKernelCommandLine=czechlight=__MODEL__
[Service]
-Type=simple
+Type=notify
ExecStart=/usr/bin/cla-sysrepod --io-log-level=5 --properties-log-level=5 --sr-bridge-log-level=5 --sysrepo-log-level=3 --appliance=__MODEL__
PrivateTmp=yes
PrivateDevices=no