kvm: Use -display none rather than -nographic
[ganeti-local] / doc / design-2.1.rst
index a48f4fd..0251fef 100644 (file)
@@ -229,8 +229,40 @@ Optimization: There's no need to touch the queue if there are no pending
 acquires and no current holders. The caller can have the lock
 immediately.
 
-.. image:: design-2.1-lock-acquire.png
+.. digraph:: "design-2.1-lock-acquire"
 
+  graph[fontsize=8, fontname="Helvetica"]
+  node[fontsize=8, fontname="Helvetica", width="0", height="0"]
+  edge[fontsize=8, fontname="Helvetica"]
+
+  /* Actions */
+  abort[label="Abort\n(couldn't acquire)"]
+  acquire[label="Acquire lock"]
+  add_to_queue[label="Add condition to queue"]
+  wait[label="Wait for notification"]
+  remove_from_queue[label="Remove from queue"]
+
+  /* Conditions */
+  alone[label="Empty queue\nand can acquire?", shape=diamond]
+  have_timeout[label="Do I have\ntimeout?", shape=diamond]
+  top_of_queue_and_can_acquire[
+    label="On top of queue and\ncan acquire lock?",
+    shape=diamond,
+    ]
+
+  /* Lines */
+  alone->acquire[label="Yes"]
+  alone->add_to_queue[label="No"]
+
+  have_timeout->abort[label="Yes"]
+  have_timeout->wait[label="No"]
+
+  top_of_queue_and_can_acquire->acquire[label="Yes"]
+  top_of_queue_and_can_acquire->have_timeout[label="No"]
+
+  add_to_queue->wait
+  wait->top_of_queue_and_can_acquire
+  acquire->remove_from_queue
 
 Release
 *******
@@ -244,7 +276,37 @@ inactive condition will be made active. This ensures fairness with
 exclusive locks by forcing consecutive shared acquires to wait in the
 queue.
 
-.. image:: design-2.1-lock-release.png
+.. digraph:: "design-2.1-lock-release"
+
+  graph[fontsize=8, fontname="Helvetica"]
+  node[fontsize=8, fontname="Helvetica", width="0", height="0"]
+  edge[fontsize=8, fontname="Helvetica"]
+
+  /* Actions */
+  remove_from_owners[label="Remove from owner list"]
+  notify[label="Notify topmost"]
+  swap_shared[label="Swap shared conditions"]
+  success[label="Success"]
+
+  /* Conditions */
+  have_pending[label="Any pending\nacquires?", shape=diamond]
+  was_active_queue[
+    label="Was active condition\nfor shared acquires?",
+    shape=diamond,
+    ]
+
+  /* Lines */
+  remove_from_owners->have_pending
+
+  have_pending->notify[label="Yes"]
+  have_pending->success[label="No"]
+
+  notify->was_active_queue
+
+  was_active_queue->swap_shared[label="Yes"]
+  was_active_queue->success[label="No"]
+
+  swap_shared->success
 
 
 Delete
@@ -518,27 +580,34 @@ A confd query will look like this, on the wire::
     "hmac": "4a4139b2c3c5921f7e439469a0a45ad200aead0f"
   }
 
-"plj0" is a fourcc that details the message content. It stands for plain
+``plj0`` is a fourcc that details the message content. It stands for plain
 json 0, and can be changed as we move on to different type of protocols
 (for example protocol buffers, or encrypted json). What follows is a
 json encoded string, with the following fields:
 
-- 'msg' contains a JSON-encoded query, its fields are:
+- ``msg`` contains a JSON-encoded query, its fields are:
+
+  - ``protocol``, integer, is the confd protocol version (initially
+    just ``constants.CONFD_PROTOCOL_VERSION``, with a value of 1)
+  - ``type``, integer, is the query type. For example "node role by
+    name" or "node primary ip by instance ip". Constants will be
+    provided for the actual available query types
+  - ``query`` is a multi-type field (depending on the ``type`` field):
+
+    - it can be missing, when the request is fully determined by the
+      ``type`` field
+    - it can contain a string which denotes the search key: for
+      example an IP, or a node name
+    - it can contain a dictionary, in which case the actual details
+      vary further per request type
 
-  - 'protocol', integer, is the confd protocol version (initially just
-    constants.CONFD_PROTOCOL_VERSION, with a value of 1)
-  - 'type', integer, is the query type. For example "node role by name"
-    or "node primary ip by instance ip". Constants will be provided for
-    the actual available query types.
-  - 'query', string, is the search key. For example an ip, or a node
-    name.
-  - 'rsalt', string, is the required response salt. The client must use
-    it to recognize which answer it's getting.
+  - ``rsalt``, string, is the required response salt; the client must
+    use it to recognize which answer it's getting.
 
-- 'salt' must be the current unix timestamp, according to the client.
-  Servers can refuse messages which have a wrong timing, according to
-  their configuration and clock.
-- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key
+- ``salt`` must be the current unix timestamp, according to the
+  client; servers should refuse messages which have a wrong timing,
+  according to their configuration and clock
+- ``hmac`` is an hmac signature of salt+msg, with the cluster hmac key
 
 If an answer comes back (which is optional, since confd works over UDP)
 it will be in this format::
@@ -554,24 +623,25 @@ it will be in this format::
 
 Where:
 
-- 'plj0' the message type magic fourcc, as discussed above
-- 'msg' contains a JSON-encoded answer, its fields are:
-
-  - 'protocol', integer, is the confd protocol version (initially just
-    constants.CONFD_PROTOCOL_VERSION, with a value of 1)
-  - 'status', integer, is the error code. Initially just 0 for 'ok' or
-    '1' for 'error' (in which case answer contains an error detail,
-    rather than an answer), but in the future it may be expanded to have
-    more meanings (eg: 2, the answer is compressed)
-  - 'answer', is the actual answer. Its type and meaning is query
-    specific. For example for "node primary ip by instance ip" queries
+- ``plj0`` the message type magic fourcc, as discussed above
+- ``msg`` contains a JSON-encoded answer, its fields are:
+
+  - ``protocol``, integer, is the confd protocol version (initially
+    just constants.CONFD_PROTOCOL_VERSION, with a value of 1)
+  - ``status``, integer, is the error code; initially just ``0`` for
+    'ok' or ``1`` for 'error' (in which case answer contains an error
+    detail, rather than an answer), but in the future it may be
+    expanded to have more meanings (e.g. ``2`` if the answer is
+    compressed)
+  - ``answer``, is the actual answer; its type and meaning is query
+    specific: for example for "node primary ip by instance ip" queries
     it will be a string containing an IP address, for "node role by
-    name" queries it will be an integer which encodes the role (master,
-    candidate, drained, offline) according to constants.
+    name" queries it will be an integer which encodes the role
+    (master, candidate, drained, offline) according to constants
 
-- 'salt' is the requested salt from the query. A client can use it to
-  recognize what query the answer is answering.
-- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key
+- ``salt`` is the requested salt from the query; a client can use it
+  to recognize what query the answer is answering.
+- ``hmac`` is an hmac signature of salt+msg, with the cluster hmac key
 
 
 Redistribute Config