Back-end service for the Nimbus node management GUI (https://github.com/status-im/nimbus-gui)
Go to file
Emil Ivanichkov f13adff445 feat(waku examples): Add examples of pairing with `js-waku` instance 2024-02-12 15:58:13 +02:00
.github/workflows fix(ci): Use the local `nim_build.sh` in `Build Nim and Nimble` step 2024-02-01 11:03:11 +02:00
docs docs: Add README 2024-01-13 22:24:59 +02:00
libs/waku-utils feat(waku examples): Add examples of pairing with `js-waku` instance 2024-02-12 15:58:13 +02:00
scripts feat(scripts): Add `build_nim.sh` script for the CI 2024-02-01 11:03:11 +02:00
src feat: Add an example confutils setup 2024-01-13 16:28:27 +02:00
tests feat: Add an example confutils setup 2024-01-13 16:28:27 +02:00
vendor chore(vendor): Add `zerokit` as submodule as `waku` needs it 2024-01-11 18:03:12 +02:00
.envrc chore(env): Add nix dev env 2024-01-09 15:16:31 +02:00
.gitignore feat: Add an example confutils setup 2024-01-13 16:28:27 +02:00
.gitmodules chore(vendor): Add `zerokit` as submodule as `waku` needs it 2024-01-11 18:03:12 +02:00
Makefile build(Makefile): Set up `libbacktrace` make instructions 2024-02-02 21:07:13 +02:00
README.md docs: Add README 2024-01-13 22:24:59 +02:00
config.nims config(nimcache) Use full path for nim cache in `config.nims` 2024-02-02 21:07:13 +02:00
flake.lock chore(nix): Update `nim` version to `1.6.18` in the dev env 2024-01-19 16:15:51 +02:00
flake.nix chore(nix): Update `nim` version to `1.6.18` in the dev env 2024-01-19 16:15:51 +02:00
nimble.lock chore(nimble): Update `nimble.lock` file 2024-01-19 16:16:08 +02:00
status_node_manager.nimble chore(nimble): Add `libbacktrace` to the dependencies 2024-02-02 21:07:13 +02:00
status_node_manager.nims chore: rename to status_node_manager; config: make sure nimble test works 2024-01-13 15:20:46 +02:00

README.md

Status Node Manager

The Status node manager is the back-end service for the Nimbus node management GUI. The GUI is focused to the Nimbus consensus layer at the moment, but it will eventually support other Logos node types, such as Nimbus EL, Fluffy, Codex, Waku and Nomos.

Configuration

The GUI app connects to the node manager through the Waku protocol. This ensures that a persistent pairing between the two can be established without any networking configuration (i.e. the user doesn't have to specify IP addresses and ports of the running Nimbus instances) and that not even metadata regarding the connection is leaked to anyone. The locally running Nimbus node can bind its REST API and metrics port to localhost and the Status node manager can make them available to the GUI through a HTTP-over-Waku transport.

The pairing protocol is very simple: The user clicks on a "Connect to Node Manager" button in the GUI which generates a random numeric ID. The user can then simply run the command nimbus pair <random-id> on the host where the node manager is installed to complete the process.

Functionality

Once configured, the node manager supports the following functionality:

  • It allows the user to manage the set of validator keys on the managed nodes (including the ability to generate and execute deposit transactions in order to create new validators).
  • It provides access to the REST APIs and metrics of the managed nodes. It delivers useful notifications, alerts and actionable diagnostic information that can help the user maintain the optimal performance of their validators.
  • It keeps track of new releases of the Nimbus consensus layer and its own command-line management utilities.
  • It can upgrade and roll-back any of the above components in zero-downtime fashion. The initial version of the zero-downtime upgrade procedure will take advantage of the "time to next action" metric of the Nimbus beacon node.
  • It can perform upgrades automatically. The user is free to enable or disable this policy and also to specify an upgrade delay period (e.g. 2 weeks) in order to allow for potential problems to be discovered by more active early adopters.
  • The user can remotely start new Nimbus nodes connected to different networks (e.g. testnets). The Status node manager then either acts as a simple supervisor for the started processes or it can leverage Systemd for the same purpose.