Prepare plan for upgrades

[CyrilBrulebois]

At the moment we're not doing anything in the pirogue-admin-ified packages except shipping an index.yaml and possibly some templates. That's working out just fine since the initial configuration is done via pirogue-admin (autodetection then applying the generated config) called from pirogue-base.postinst.

That works fine for the initial deployment but an updated package (e.g. pirogue-networking shipping a new override) wouldn't trigger a configuration update.

One way to deal with that could be to have those packages use a dpkg trigger, but that could be problematic depending on the exact ordering + set(s) of packages getting installed. Another way to look at it might be to have them register themselves/trigger something that could be noticed by the pirogue-admin server once it's implemented, so that it can re-deploy the configuration once apt/dpkg have stopped running.

[CyrilBrulebois]

Discussed today: let's not wait for a server. Instead, add support for some --deploy-configuration-after-package-upgrade option (or much shorter) in /usr/sbin/pirogue-admin, and have all pirogue-admin-ified packages call it from their postinst.

While doing so, skip the call on initial installation (pirogue-base.postinst should be last to run, asking for autodetection then submitting it), only do that during upgrades.

It seems cleaner to add a Depends: pirogue-admin while doing so. A versioned dependency could be used whenever a new variable/type/etc. is introduced, to make sure pirogue-admin:

• doesn't error out because of the new thing it doesn't know about;
• can try and adapt the current configuration with a reasonable value for the new variable.

[CyrilBrulebois]

Initial --redeploy --commit support added, avoiding having to pass --apply /path/to/current/config.yaml --commit in each postinst script (using existing semantics/options).

Validated using an updated pirogue-networking package, adding that postinst and a modified systemd override, and results look good.

At least one question remains: should we error out (and make the postinst exit, failing the package's configuration at the dpkg level) if there's no current configuration? Or just log a warning? The initial implementation does the latter. At least in a package context, we should only call that when upgrading packages, while the initial installation, probably triggered by installing pirogue-base should have led to autodetection + initial config deployment, including writing the config file…

[CyrilBrulebois]

Considering this topic covered until further notice. The implementation detail regarding a --redeploy before the initial configuration has happened can be documented in the developer-oriented documentation I'm going to write.