Currently CLI and UI initialize cluster differently (order of operations mostly) which makes modification and testing of the init procedure very painful.
For example, when initialization is done via UI it sets ip family and encryption settings first, then renames the node. At the same time CLI sets ip family then renames the node, and assumes that encryption will be modified after it (or maybe before it, not clear). At the same order of these operations is very important.
It seems to makes sense to move node-init and cluster-init logic to ns_server, while CLI and UI can simply call those endpoints. In this case if we need to modify the init procedure we modify it in ns_server and don't touch neither UI nor CLI.
Currently according to CLI:
node-init consists of
1) POST /nodes/self/controller/settings (setting data paths)
2) (3 calls to set address family)
3) POST /node/controller/rename
Cluster-init consists of
1) POST /pools/default (set quotas)
2) POST /settings/indexes (set index storage mode)
3) POST /node/controller/setupServices
4) POST /settings/stats (Enable notifications)
5) POST /settings/web (set credentials)
UI does the same (+ sets encryption) but in different order.
My suggestion is to move the logic of the node-init and cluster-init to ns_server (to POST /nodeInit and POST clusterInit).
CLI node-init command will call one endpoint POST /nodeInit.
CLI cluster-init command will call one endpoint POST /clusterInit
UI create cluster wizard will call both of them.
Another benefit of this change is that it will give us a chance to make initialization much faster. For example, currently we restart ns_server three times during node-init (worst case), which can be replaced with one restart.
Change of ip family can be done simpler as well in that case.