design-2.1: clarify confd usage of serial numbers
authorGuido Trotter <ultrotter@google.com>
Thu, 20 Aug 2009 10:01:57 +0000 (12:01 +0200)
committerGuido Trotter <ultrotter@google.com>
Thu, 20 Aug 2009 10:26:17 +0000 (12:26 +0200)
Signed-off-by: Guido Trotter <ultrotter@google.com>
Reviewed-by: Iustin Pop <iustin@google.com>

doc/design-2.1.rst

index db97b2d..a19f835 100644 (file)
@@ -118,10 +118,11 @@ using HMAC with a cluster-wide shared key.
 
 An interested client can query a value by making a request to a subset of the
 cluster master candidates. It will then wait to get a few responses, and use
 
 An interested client can query a value by making a request to a subset of the
 cluster master candidates. It will then wait to get a few responses, and use
-the one with the highest configuration serial number (which will be always
-included in the answer). If some candidates are stale, or we are in the middle
-of a configuration update, various master candidates may return different
-values, and this should make sure the most recent information is used.
+the one with the highest configuration serial number. Since the configuration
+serial number is increased each time the ganeti config is updated, and the
+serial number is included in all answers, this can be used to make sure to use
+the most recent answer, in case some master candidates are stale or in the
+middle of a configuration update.
 
 In order to prevent replay attacks queries will contain the current unix
 timestamp according to the client, and the server will verify that its
 
 In order to prevent replay attacks queries will contain the current unix
 timestamp according to the client, and the server will verify that its