Right now, the management API can only be called through fdbcli. We plan to expose some of them through the special-key-space, which makes it possible to use multi-version clients for the management API. There are many configuration commands in fdbcli able to expose through special-key-space like
include, exclude, setclass as they are transactional-based. Since the current implementation of special-key-space is transactional-based, any commands not completed through a transaction object is not able to do so.
Now we come to the design for the schema of each management command. Let’s take
exclude as the start point. If we can agree on how to encode these two, then other commands should follow the same way.
The current fdbcli command for
exclude [FORCE] [failed] [no_wait] <ADDRESS>*
Our proposal is to map
exclude <ADDRESS>* to a set fdb call like:
set("\xff\xff/configuration/exclude/<ADDRESS>*" , "true if failed | false")
In this case, the include all command is translated into:
and include <ADDRESS>* is translated into:
For include <IP>, it comes with
For exclude , which lists all excluded servers:
Similarly, setclass <unset|storage|transaction|default> is formatted as:
However, by doing this, we are actually always doing
no_wait flag and it is also unable to specify the
FORCE flag in the
set statement since the
set is happening locally. In general, the way described above is not well-defined to specify optional flags like
no_wait for the command.
The design of the schema needs discussion. Any questions, ideas or comments will be super helpful.