kvm: Use -display none rather than -nographic

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

diff --git a/doc/design-2.0.rst b/doc/design-2.0.rst
index c2c4591..6bff30a 100644 (file)
--- a/doc/design-2.0.rst
+++ b/doc/design-2.0.rst
@@ -102,7 +102,44 @@ these operations are scheduled internally will change radically.
 
 The new design will change the cluster architecture to:
 
-.. image:: arch-2.0.png
+.. digraph:: "ganeti-2.0-architecture"
+
+  compound=false
+  concentrate=true
+  mclimit=100.0
+  nslimit=100.0
+  edge[fontsize="8" fontname="Helvetica-Oblique"]
+  node[width="0" height="0" fontsize="12" fontcolor="black" shape=rect]
+
+  subgraph outside {
+    rclient[label="external clients"]
+    label="Outside the cluster"
+  }
+
+  subgraph cluster_inside {
+    label="ganeti cluster"
+    labeljust=l
+    subgraph cluster_master_node {
+      label="master node"
+      rapi[label="RAPI daemon"]
+      cli[label="CLI"]
+      watcher[label="Watcher"]
+      burnin[label="Burnin"]
+      masterd[shape=record style=filled label="{ <luxi> luxi endpoint | master I/O thread | job queue | {<w1> worker| <w2> worker | <w3> worker }}"]
+      {rapi;cli;watcher;burnin} -> masterd:luxi [label="LUXI" labelpos=100]
+    }
+
+    subgraph cluster_nodes {
+        label="nodes"
+        noded1 [shape=record label="{ RPC listener | Disk management | Network management | Hypervisor } "]
+        noded2 [shape=record label="{ RPC listener | Disk management | Network management | Hypervisor } "]
+        noded3 [shape=record label="{ RPC listener | Disk management | Network management | Hypervisor } "]
+    }
+    masterd:w2 -> {noded1;noded2;noded3} [label="node RPC"]
+    cli -> {noded1;noded2;noded3} [label="SSH"]
+  }
+
+  rclient -> rapi [label="RAPI protocol"]
 
 This differs from the 1.2 architecture by the addition of the master
 daemon, which will be the only entity to talk to the node daemons.
@@ -187,6 +224,8 @@ format and decode them on the receiver side.
 For more details about the RAPI daemon see `Remote API changes`_, and
 for the node daemon see `Node daemon changes`_.
 
+.. _luxi:
+
 The LUXI protocol
 +++++++++++++++++
 
@@ -294,9 +333,6 @@ failover:
       determined by the serial number on the configuration and
       highest job ID on the job queue)
 
-    - there is not even a single node having a newer
-      configuration file
-
     - if we are not failing over (but just starting), the
       quorum agrees that we are the designated master
 
@@ -609,6 +645,8 @@ be leaf locks or carefully structured non-leaf ones, to avoid deadlock
 race conditions.
 
 
+.. _jqueue-original-design:
+
 Job Queue
 ~~~~~~~~~
 
@@ -961,10 +999,10 @@ Opcode changes
 The parameter changes will have impact on the OpCodes, especially on
 the following ones:
 
-- ``OpCreateInstance``, where the new hv and be parameters will be sent
+- ``OpInstanceCreate``, where the new hv and be parameters will be sent
   as dictionaries; note that all hv and be parameters are now optional,
   as the values can be instead taken from the cluster
-- ``OpQueryInstances``, where we have to be able to query these new
+- ``OpInstanceQuery``, where we have to be able to query these new
   parameters; the syntax for names will be ``hvparam/$NAME`` and
   ``beparam/$NAME`` for querying an individual parameter out of one
   dictionary, and ``hvparams``, respectively ``beparams``, for the whole
@@ -1583,7 +1621,7 @@ DEBUG_LEVEL
 
 These are only the basic variables we are thinking of now, but more
 may come during the implementation and they will be documented in the
-:manpage:`ganeti-os-api` man page. All these variables will be
+:manpage:`ganeti-os-interface(7)` man page. All these variables will be
 available to all scripts.
 
 Some scripts will need a few more information to work. These will have
@@ -1684,7 +1722,7 @@ response body. Typical examples of queries would be: list of nodes,
 instances, cluster info, etc.
 
 In the case of job submission, the client receive a job ID, the
-identifier which allows to query the job progress in the job queue
+identifier which allows one to query the job progress in the job queue
 (see `Job Queue`_).
 
 Internally, each exported object has an version identifier, which is