Merge branch 'stable-2.7' into stable-2.8

[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
 
 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.
 
 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
    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.
    - 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
 
    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
      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 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
      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
 
    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
      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.
 
 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
 ==========================
 
 External interface changes
 ==========================