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 include and 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 and include:
exclude [FORCE] [failed] [no_wait] <ADDRESS>*
include all|<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:
clearrange("\xff\xff/configuartion/exclude", "\xff\xff/configuaration/exclude0")
and include <ADDRESS>* is translated into:
clear("\xff\xff/configuration/exclude/<ADDRESS>*")
For include <IP>, it comes with
clearrange("\xff\xff/configuration/exclude/<IP>", "\xff\xff/configuration/exclude/<IP>\xff")
For exclude , which lists all excluded servers:
getrange("\xff\xff/configuration/exclude", "\xff\xff/configuration/exclude0")
Similarly, setclass <unset|storage|transaction|default> is formatted as:
set("\xff\xff/configuration/class/<ADDRESS>", <unset|storage|transaction|default>)
However, by doing this, we are actually always doing exclude with 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 FORCE no_wait for the command.
The design of the schema needs discussion. Any questions, ideas or comments will be super helpful.