This version instead still requires --yes with --restart to avoid the
confirmation option, but avoids duplicate prompts.
This might be slightly more cumbersome, but ensures consistency: every
situation that could cause a restart is confirmed even if --restart is
given.
Having both restart_opt and confirm_opt resulted in a duplicate
confirmation message, at least if neither --restart/--no-restart is
specified. This is not necessary as the confirmation is already given by
the restart_opt or the relevant --restart/--no-restart flag.
If "--live" is passed (the default), we shouldn't confirm to restart the
VM as this is not required. Instead only confirm if "--no-live" was
passed or if the flag doesn't exist.
1. Add a cron mode to avoid exit(1) during cronjobs/timers
2. Revamp the remote_mount settings into auto_mount
This removes a lot of unnecessary complexity while giving the
administrator more flexibility in what they want to execute to mount
a filesystem and how. The naming reflects the goal but the possible
commands are arbitrary.
Adds autobackup (integrated, managed VM backups with automatic remote
filesystem mounting, included backup expiry/removal and automatic
full/incremental selection, independent from the manual "pvc vm backup"
commands) to the CLI client.
This is a bit of a large command to handle only inside the CLI client,
but this was chosen as it's the only real place for it aside from an
external script.
There are several major restrictions on this command, mainly that it
must be run from the primary coordinator using the "local" connection,
and that it must be run as "root".
The command is designed to run in a cron/systemd timer installed by
pvc-ansible when the appropriate group_vars are enabled, and otherwise
not touched.
Also clean up the old versions in the postinst as they are obsolete and
not needed going forward. These only ever served as reference for a
manual installation which itself is long-obsoleted, and thus can be put
somewhere less "important".
This helps ensure an easier restore as the tar archive(s) can be sent
directly to the API via the normal process of image uploading, instead
of individual disks.
Joshua Boniface