Revision a9407509
b/doc/design-2.1.rst | ||
---|---|---|
131 | 131 |
answers which contain salt generated by them. |
132 | 132 |
|
133 | 133 |
The configuration daemon will be able to answer simple queries such as: |
134 |
|
|
134 | 135 |
- master candidates list |
135 | 136 |
- master node |
136 | 137 |
- offline nodes |
137 | 138 |
- instance list |
138 | 139 |
- instance primary nodes |
139 | 140 |
|
141 |
Wire protocol |
|
142 |
^^^^^^^^^^^^^ |
|
143 |
|
|
144 |
A confd query will look like this, on the wire:: |
|
145 |
|
|
146 |
{ |
|
147 |
"msg": "{\"type\": 1, |
|
148 |
\"rsalt\": \"9aa6ce92-8336-11de-af38-001d093e835f\", |
|
149 |
\"protocol\": 1, |
|
150 |
\"query\": \"node1.example.com\"}\n", |
|
151 |
"salt": "1249637704", |
|
152 |
"hmac": "4a4139b2c3c5921f7e439469a0a45ad200aead0f" |
|
153 |
} |
|
154 |
|
|
155 |
Detailed explanation of the various fields: |
|
156 |
|
|
157 |
- 'msg' contains a JSON-encoded query, its fields are: |
|
158 |
|
|
159 |
- 'protocol', integer, is the confd protocol version (initially just |
|
160 |
constants.CONFD_PROTOCOL_VERSION, with a value of 1) |
|
161 |
- 'type', integer, is the query type. For example "node role by name" or |
|
162 |
"node primary ip by instance ip". Constants will be provided for the actual |
|
163 |
available query types. |
|
164 |
- 'query', string, is the search key. For example an ip, or a node name. |
|
165 |
- 'rsalt', string, is the required response salt. The client must use it to |
|
166 |
recognize which answer it's getting. |
|
167 |
|
|
168 |
- 'salt' must be the current unix timestamp, according to the client. Servers |
|
169 |
can refuse messages which have a wrong timing, according to their |
|
170 |
configuration and clock. |
|
171 |
- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key |
|
172 |
|
|
173 |
If an answer comes back (which is optional, since confd works over UDP) it will |
|
174 |
be in this format:: |
|
175 |
|
|
176 |
{ |
|
177 |
"msg": "{\"status\": 0, |
|
178 |
\"answer\": 0, |
|
179 |
\"serial\": 42, |
|
180 |
\"protocol\": 1}\n", |
|
181 |
"salt": "9aa6ce92-8336-11de-af38-001d093e835f", |
|
182 |
"hmac": "aaeccc0dff9328fdf7967cb600b6a80a6a9332af" |
|
183 |
} |
|
184 |
|
|
185 |
Where: |
|
186 |
|
|
187 |
- 'msg' contains a JSON-encoded answer, its fields are: |
|
188 |
|
|
189 |
- 'protocol', integer, is the confd protocol version (initially just |
|
190 |
constants.CONFD_PROTOCOL_VERSION, with a value of 1) |
|
191 |
- 'status', integer, is the error code. Initially just 0 for 'ok' or '1' for |
|
192 |
'error' (in which case answer contains an error detail, rather than an |
|
193 |
answer), but in the future it may be expanded to have more meanings (eg: 2, |
|
194 |
the answer is compressed) |
|
195 |
- 'answer', is the actual answer. Its type and meaning is query specific. For |
|
196 |
example for "node primary ip by instance ip" queries it will be a string |
|
197 |
containing an IP address, for "node role by name" queries it will be an |
|
198 |
integer which encodes the role (master, candidate, drained, offline) |
|
199 |
according to constants. |
|
200 |
|
|
201 |
- 'salt' is the requested salt from the query. A client can use it to recognize |
|
202 |
what query the answer is answering. |
|
203 |
- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key |
|
204 |
|
|
140 | 205 |
|
141 | 206 |
Redistribute Config |
142 | 207 |
~~~~~~~~~~~~~~~~~~~ |
Also available in: Unified diff