This design document introduces the gnt-disk command, so that disks can be treated as top-level entities.
Signed-off-by: Lisa Velden <[email protected]> --- Makefile.am | 3 +- doc/design-draft.rst | 1 + doc/design-standalone-disks.rst | 161 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164 insertions(+), 1 deletion(-) create mode 100644 doc/design-standalone-disks.rst diff --git a/Makefile.am b/Makefile.am index 0080f00..f93aac6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -546,7 +546,7 @@ hypervisor_hv_kvm_PYTHON = \ jqueue_PYTHON = \ lib/jqueue/__init__.py \ - lib/jqueue/exec.py \ + lib/jqueue/exec.py \ lib/jqueue/post_hooks_exec.py storage_PYTHON = \ @@ -733,6 +733,7 @@ docinput = \ doc/design-shared-storage.rst \ doc/design-shared-storage-redundancy.rst \ doc/design-ssh-ports.rst \ + doc/design-standalone-disks.rst \ doc/design-storagetypes.rst \ doc/design-sync-rate-throttling.rst \ doc/design-systemd.rst \ diff --git a/doc/design-draft.rst b/doc/design-draft.rst index e4c9f85..18d9ca9 100644 --- a/doc/design-draft.rst +++ b/doc/design-draft.rst @@ -28,6 +28,7 @@ Design document drafts design-global-hooks.rst design-scsi-kvm.rst design-disks.rst + design-standalone-disks.rst .. vim: set textwidth=72 : .. Local Variables: diff --git a/doc/design-standalone-disks.rst b/doc/design-standalone-disks.rst new file mode 100644 index 0000000..37b68ee --- /dev/null +++ b/doc/design-standalone-disks.rst @@ -0,0 +1,161 @@ +========================= +Disks as Separate Objects +========================= + +.. contents:: :depth: 3 + +This design document improves the former :doc:`design-disks` document. +It introduces the gnt-disk command, so that disks can really be treated +as top-level entities. However, the focus is on disks as separate objects, +that is, we do not introduce other new features, such as instances with +mixed disk templates. + + +Current state and shortcomings +============================== + +What can already be done? +------------------------- + +Currently, disks can only be created within an instance. But it is +already possible to have disks reside in the configuration without being +tied to an instance if that disk was previously detached from an +instance with a modification command like +``gnt-instance modify --disk *UUID*:detach *INSTANCE*``. + +However, detaching a disk from an instance results in a warning in +``gnt-cluster verify`` about orphan volumes for most of the disk +templates. + +Besides detaching, it is also possible to attach a pre-existing disk to +an instance and to adopt disks into the Ganeti configuration which have +been created outside of Ganeti, e.g. on plain KVM with LVM. Currently, +disk adoption is done with ``gnt-instance add --disk=*N*:adopt=*LV*``, +which means it is adopt and attach in one step. + +It is possible to list all disks on a node with their associated +instances, if any. The command for that is ``gnt-node volumes``. However, +only LVM volumes are listed with that command. + +Furthermore, instances can be destroyed while its disks are left as is. +But therefore disks have to be detached first and +``gnt-instance remove`` has to be called afterwards. + +What cannot be done at the current state? +----------------------------------------- + +Standalone disks cannot be properly accessed. There is no command that +lists all disks for all disk templates, nor is it easy to find the +respective instance, if any, for a given disk. + +It is also not convenient that detached disks can only be removed when +they are attached to an instance again and that disk adoption only works +for lvm volumes and block devices at the current state. + +Currently, disk adoption only works with plain and blockdev disk +templates. It should also work with the ext disk template, so that in a +shared storage environment we can do cross-cluster failovers, where we +instantaneously move an instance from one cluster to another. + +Proposed changes +================ + +As the current way to do disk adoption as well as removing detached +disks from the Ganeti configuration is not intuitive, we propose to +introduce a new command ``gnt-disk`` that supports the following +subcommands: + +* ``gnt-disk info *DISK_UUID|DISK_NAME*``: all relevant information for + a disk is listed, e.g. size, connected instance, position among other + disks + +* ``gnt-disk list``: disks that should be listed can be specified with + ``--attached``, ``--detached`` or ``--all`` where all disks are also + shown as default if no option was given + +* ``gnt-disk adopt *VOLUME*``: adopts a volume into the Ganeti + configuration. This should work not only for plain and block devices, + but also for shared storage. + +* ``gnt-disk create --disk-template *DT* --size *VAL* options``: creates + a disk, so that it appears in the Ganeti configuration. This command + will take the same options as ``gnt-instance add --disk`` except for + the position value and the adopt option. + +* ``gnt-disk modify *DISK_UUID|DISK_NAME* options``: changes the options + of the disk. Available options are + + + ``mode``: The access mode, i.e. either ``ro`` (read-only) or the + default ``rw`` (read-write). + + ``name``: This option specifies a name for the disk that can be + used as an identifier. + +* ``gnt-disk abandon *DISK_UUID|DISK_NAME*``: removes the given disk from + the Ganeti configuration without destroying the disk. With an + additional option ``--remove-data`` the disk will also be destroyed. + +* ``gnt-disk snapshot [--target-disk-name *NAME*] + *SRC_DISK_UUID|SRC_DISK_NAME*``: creates a snapshot of the given source + disk. This will be a new disk with the specified name and read-only + access mode + +* ``gnt-disk clone [--target-disk-name *NAME*] + *SRC_DISK_UUID|SRC_DISK_NAME*``: creates a new disk with read-write + access mode and optionally with a given disk name + +* ``gnt-disk convert --target-disk-template *DT* *DISK_UUID|DISK_NAME*``: + converts the disk template of a disk into the new disk template + +* ``gnt-disk copy [--target-disk-name *NAME*] --target-disk-template *DT* + *SRC_DISK_UUID|SRC_DISK_NAME*``: creates a new disk that is identical + to the source disk, but has a different disk template + +Besides the ``gnt-disk`` command, we propose the following changes: + +* Make the storage path information retrieved from the logical id from + disks also available through the basic instance information from the + RAPI + +* Disallow all disk operations via the RAPI, except for moves + +* Add a flag to preserve disks to the ``gnt-instance remove`` command + +Further possible changes +======================== + +If there is need for it, it would be also possible to move disk +detachment and attachment to the new ``gnt-disk`` command, so that we +would have the following simplified commands, instead of the respective +``gnt-instance modify --disk`` commands: + +* ``gnt-disk attach [--position *N*] {--uuid *DISK_UUID* | --name + *DISK_NAME*} *INSTANCE*``: attaches a disk to an instance. If the disk + was not in the configuration before, an error is raised. If no position + argument was provided, the disk will be attached at the last index of + the instance's disks. + +* ``gnt-disk detach {--uuid *DISK_UUID* | --name *DISK_NAME* | --position + *N*} *INSTANCE*``: detaches a disk from an instance and leaves it in + the Ganeti configuration + +Note that this does not add new functionality, because it will behave +just as the current solution for disk attachment and detachment. For +example, disk attachment might still fail due to misaligned DRBD disks. + +Implementation details +====================== + +Especially for the ``gnt-disk create`` part it will be handy to re-factor +the current ``LUInstanceCreate`` in such a way that we can reuse the disk +creation part. That can be achieved with tasklets like they are used +in ``LUInstanceMigrate`` and ``LUInstanceReplaceDisks``. The same holds +for ``LUInstanceSetParams``, because we want to be able to make disk +changes also to standalone disks. + +Except for creating diskless instances on purpose, the diskless disk +template should not be required if an instance becomes diskless, but the +instance should be considered to be in the state ``diskless``. + +The logic for adoption should be moved down to ``lib/storage/bdev.py``, +so that it becomes uniform to all disk templates and it is, thus, easy to +extend it for external storage. -- 2.7.0.rc3.207.g0ac5344
