implement remote control cli (#12) #36
Loading…
Reference in a new issue
No description provided.
Delete branch "features/cli"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
64b16d4f0df6dbe2a0d2f6dbe2a0d205c9ead93b05c9ead93baabe0b385caabe0b385c20452f13bcWIP: implement remote control cli (#12)to implement remote control cli (#12)20452f13bc57f309509e57f309509e1f3ac37bf41f3ac37bf4e2118e142de2118e142d1fe097aacb1fe097aacb0a757e779dI like the use of the builder pattern throughout. I don't see anything concerning, but I want to make sure I understand the CLI.
@ -56,2 +57,4 @@enddef start_phase(:maybe_start_node, _start_type, _phase_args) doif Config.get([:cluster, :enabled]) doI'm going to have to research Erlang clusters more to really properly review this part at some later point.
For now this switch just allowes Erlang node to be started and nothing more. The same options we can use in future for real cluster configuration.
During the development I just executed Bromal (https://dev3.bromal.im) with something like (note
--snameparam):The contents of
../bromal.dev.tomlfile:@serra wrote in #36 (comment):
To my mind, the 'builder pattern' makes a code a little bit cleaner and more maintainable even in small
bromalctlscript, however it is not super-widely used in Erlang/Elixir world.For now it uses hidden node, just for RPC purpose, but it really doesn't matter, as we have no clustering at all. In future we can support clustering with node autodetection, consensus, etc.
Yes, it uses standard Erlang's inter-node communication protocol/RPC interface nearly out-of-box, so no need to implement something REST-based, such as in other programming languages/development stacks.
I think, yes. It can also be easily extended for any kind of admin purposes and other scripts. For now
bromalctlis just a standalone script for very base tasks related to server maintaining.Pull request closed