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:
 
 
 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.
 
 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`_.
 
 For more details about the RAPI daemon see `Remote API changes`_, and
 for the node daemon see `Node daemon changes`_.
 

+.. _luxi:
+

 The LUXI protocol
 +++++++++++++++++
 
 The LUXI protocol
 +++++++++++++++++
 

@@ -294,9 +333,6 @@ failover:
       determined by the serial number on the configuration and
       highest job ID on the job queue)
 
       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
 
     - 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.
 
 
 race conditions.
 
 

+.. _jqueue-original-design:
+

 Job Queue
 ~~~~~~~~~
 
 Job Queue
 ~~~~~~~~~
 

@@ -961,10 +999,10 @@ Opcode changes
 The parameter changes will have impact on the OpCodes, especially on
 the following ones:
 
 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
   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
   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
 
 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
 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
 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
 (see `Job Queue`_).
 
 Internally, each exported object has an version identifier, which is