kvm: Use -display none rather than -nographic

[ganeti-local] / doc / design-2.2.rst

diff --git a/doc/design-2.2.rst b/doc/design-2.2.rst
index 2c8cf55..5af014a 100644 (file)
--- a/doc/design-2.2.rst
+++ b/doc/design-2.2.rst
@@ -286,8 +286,8 @@ level only, allowing us to easily support non-DRBD instance moves.
 
 Intra-cluster instance moves will re-use the existing export and import
 scripts supplied by instance OS definitions. Unlike simply copying the
-raw data, this allows to use filesystem-specific utilities to dump only
-used parts of the disk and to exclude certain disks from the move.
+raw data, this allows one to use filesystem-specific utilities to dump
+only used parts of the disk and to exclude certain disks from the move.
 Compression should be used to further reduce the amount of data
 transferred.
 
@@ -303,7 +303,7 @@ Workflow
    instance specification and for the public part of an encryption key
 
    - Instance information can already be retrieved using an existing API
-     (``OpQueryInstanceData``).
+     (``OpInstanceQueryData``).
    - An RSA encryption key and a corresponding self-signed X509
      certificate is generated using the "openssl" command. This key will
      be used to encrypt the data sent to the destination cluster.
@@ -317,7 +317,7 @@ Workflow
    instance move with the key received from the source cluster and
    receives the public part of the destination's encryption key
 
-   - The current API to create instances (``OpCreateInstance``) will be
+   - The current API to create instances (``OpInstanceCreate``) will be
      extended to support an import from a remote cluster.
    - A valid, unexpired X509 certificate signed with the destination
      cluster's secret will be required. By verifying the signature, we
@@ -329,7 +329,7 @@ Workflow
 
    - The destination cluster generates another key and certificate,
      signs and sends it to the third party, who will have to pass it to
-     the API for exporting an instance (``OpExportInstance``). This
+     the API for exporting an instance (``OpBackupExport``). This
      certificate is used to ensure we're sending the disk data to the
      correct destination cluster.
    - Once a disk can be imported, the API sends the destination
@@ -340,7 +340,7 @@ Workflow
    together with all necessary information to source cluster and tells
    it to start the move
 
-   - The existing API for exporting instances (``OpExportInstance``)
+   - The existing API for exporting instances (``OpBackupExport``)
      will be extended to export instances to remote clusters.
 
 #. Source cluster connects to destination cluster for each disk and
@@ -686,6 +686,51 @@ kvm processes, and extend the user limitation to use a user pool.
 Finally we'll look into namespaces and containers, although that might
 slip after the 2.2 release.
 
+New OS states
+-------------
+
+Separate from the OS external changes, described below, we'll add some
+internal changes to the OS.
+
+Current state and shortcomings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are two issues related to the handling of the OSes.
+
+First, it's impossible to disable an OS for new instances, since that
+will also break reinstallations and renames of existing instances. To
+phase out an OS definition, without actually having to modify the OS
+scripts, it would be ideal to be able to restrict new installations but
+keep the rest of the functionality available.
+
+Second, ``gnt-instance reinstall --select-os`` shows all the OSes
+available on the clusters. Some OSes might exist only for debugging and
+diagnose, and not for end-user availability. For this, it would be
+useful to "hide" a set of OSes, but keep it otherwise functional.
+
+Proposed changes
+~~~~~~~~~~~~~~~~
+
+Two new cluster-level attributes will be added, holding the list of OSes
+hidden from the user and respectively the list of OSes which are
+blacklisted from new installations.
+
+These lists will be modifiable via ``gnt-os modify`` (implemented via
+``OpClusterSetParams``), such that even not-yet-existing OSes can be
+preseeded into a given state.
+
+For the hidden OSes, they are fully functional except that they are not
+returned in the default OS list (as computed via ``OpOsDiagnose``),
+unless the hidden state is requested.
+
+For the blacklisted OSes, they are also not shown (unless the
+blacklisted state is requested), and they are also prevented from
+installation via ``OpInstanceCreate`` (in create mode).
+
+Both these attributes are per-OS, not per-variant. Thus they apply to
+all of an OS' variants, and it's impossible to blacklist or hide just
+one variant. Further improvements might allow a given OS variant to be
+blacklisted, as opposed to whole OSes.
 
 External interface changes
 ==========================