By default, tasks will continue to run as they did, on the primary
coordinator's task runner. However this opens the possibility for
defining more tasks that will run on other nodes or coordinators.
Redis did not provide a distributed solution for the worker, which
precluded several important planned functions. So instead, move to using
Zookeeper + PostgreSQL as the broker and result backend respectively.
Should be a seamless drop-in change but for future uses requires the
database host to be the primary coordinator IP rather than localhost, so
that writes can occur to the database from non-primary hosts.
1. Simplify this by leveraging the existing remove_osd/add_osd
functions, since its task was functionally identical to those two in
sequential order.
2. Add support for split OSDs within the command (replacing all OSDs on
the block device(s) as required).
3. Add additional configurability and flexibility around the old device,
weight, and external DB LVs.
Allows creating multiple OSDs on a single (NVMe) block device,
leveraging the "ceph-volume lvm batch" command. Replaces the previous
method of creating OSDs.
Also adds a new ZK item for each OSD indicating if it is split or not.
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.
Joshua Boniface