tree d957546a41f6835bf1eee7e8c69b5a618ab02302
parent 269d70f1fe5efc618efb02411d8a01714f1aec4e
author Jan Kundrát <kundrat@cesnet.cz> 1604351416 +0100
committer Jan Kundrát <kundrat@cesnet.cz> 1604410633 +0100

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