Revision 530b64e6 doc/design-2.1.rst
b/doc/design-2.1.rst | ||
---|---|---|
518 | 518 |
"hmac": "4a4139b2c3c5921f7e439469a0a45ad200aead0f" |
519 | 519 |
} |
520 | 520 |
|
521 |
"plj0" is a fourcc that details the message content. It stands for plain
|
|
521 |
``plj0`` is a fourcc that details the message content. It stands for plain
|
|
522 | 522 |
json 0, and can be changed as we move on to different type of protocols |
523 | 523 |
(for example protocol buffers, or encrypted json). What follows is a |
524 | 524 |
json encoded string, with the following fields: |
525 | 525 |
|
526 |
- 'msg' contains a JSON-encoded query, its fields are:
|
|
526 |
- ``msg`` contains a JSON-encoded query, its fields are:
|
|
527 | 527 |
|
528 |
- 'protocol', integer, is the confd protocol version (initially just |
|
529 |
constants.CONFD_PROTOCOL_VERSION, with a value of 1) |
|
530 |
- 'type', integer, is the query type. For example "node role by name" |
|
531 |
or "node primary ip by instance ip". Constants will be provided for |
|
532 |
the actual available query types. |
|
533 |
- 'query', string, is the search key. For example an ip, or a node |
|
534 |
name. |
|
535 |
- 'rsalt', string, is the required response salt. The client must use |
|
536 |
it to recognize which answer it's getting. |
|
528 |
- ``protocol``, integer, is the confd protocol version (initially |
|
529 |
just ``constants.CONFD_PROTOCOL_VERSION``, with a value of 1) |
|
530 |
- ``type``, integer, is the query type. For example "node role by |
|
531 |
name" or "node primary ip by instance ip". Constants will be |
|
532 |
provided for the actual available query types |
|
533 |
- ``query`` is a multi-type field (depending on the ``type`` field): |
|
537 | 534 |
|
538 |
- 'salt' must be the current unix timestamp, according to the client. |
|
539 |
Servers can refuse messages which have a wrong timing, according to |
|
540 |
their configuration and clock. |
|
541 |
- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key |
|
535 |
- it can be missing, when the request is fully determined by the |
|
536 |
``type`` field |
|
537 |
- it can contain a string which denotes the search key: for |
|
538 |
example an IP, or a node name |
|
539 |
- it can contain a dictionary, in which case the actual details |
|
540 |
vary further per request type |
|
541 |
|
|
542 |
- ``rsalt``, string, is the required response salt; the client must |
|
543 |
use it to recognize which answer it's getting. |
|
544 |
|
|
545 |
- ``salt`` must be the current unix timestamp, according to the |
|
546 |
client; servers should refuse messages which have a wrong timing, |
|
547 |
according to their configuration and clock |
|
548 |
- ``hmac`` is an hmac signature of salt+msg, with the cluster hmac key |
|
542 | 549 |
|
543 | 550 |
If an answer comes back (which is optional, since confd works over UDP) |
544 | 551 |
it will be in this format:: |
... | ... | |
554 | 561 |
|
555 | 562 |
Where: |
556 | 563 |
|
557 |
- 'plj0' the message type magic fourcc, as discussed above |
|
558 |
- 'msg' contains a JSON-encoded answer, its fields are: |
|
559 |
|
|
560 |
- 'protocol', integer, is the confd protocol version (initially just |
|
561 |
constants.CONFD_PROTOCOL_VERSION, with a value of 1) |
|
562 |
- 'status', integer, is the error code. Initially just 0 for 'ok' or |
|
563 |
'1' for 'error' (in which case answer contains an error detail, |
|
564 |
rather than an answer), but in the future it may be expanded to have |
|
565 |
more meanings (eg: 2, the answer is compressed) |
|
566 |
- 'answer', is the actual answer. Its type and meaning is query |
|
567 |
specific. For example for "node primary ip by instance ip" queries |
|
564 |
- ``plj0`` the message type magic fourcc, as discussed above |
|
565 |
- ``msg`` contains a JSON-encoded answer, its fields are: |
|
566 |
|
|
567 |
- ``protocol``, integer, is the confd protocol version (initially |
|
568 |
just constants.CONFD_PROTOCOL_VERSION, with a value of 1) |
|
569 |
- ``status``, integer, is the error code; initially just ``0`` for |
|
570 |
'ok' or ``1`` for 'error' (in which case answer contains an error |
|
571 |
detail, rather than an answer), but in the future it may be |
|
572 |
expanded to have more meanings (e.g. ``2`` if the answer is |
|
573 |
compressed) |
|
574 |
- ``answer``, is the actual answer; its type and meaning is query |
|
575 |
specific: for example for "node primary ip by instance ip" queries |
|
568 | 576 |
it will be a string containing an IP address, for "node role by |
569 |
name" queries it will be an integer which encodes the role (master,
|
|
570 |
candidate, drained, offline) according to constants.
|
|
577 |
name" queries it will be an integer which encodes the role |
|
578 |
(master, candidate, drained, offline) according to constants
|
|
571 | 579 |
|
572 |
- 'salt' is the requested salt from the query. A client can use it to
|
|
573 |
recognize what query the answer is answering. |
|
574 |
- 'hmac' is an hmac signature of salt+msg, with the cluster hmac key
|
|
580 |
- ``salt`` is the requested salt from the query; a client can use it
|
|
581 |
to recognize what query the answer is answering.
|
|
582 |
- ``hmac`` is an hmac signature of salt+msg, with the cluster hmac key
|
|
575 | 583 |
|
576 | 584 |
|
577 | 585 |
Redistribute Config |
Also available in: Unified diff