Back-end service for the Nimbus node management GUI (https://github.com/status-im/nimbus-gui)
Go to file
Emil Ivanichkov b9fa56ed9b feat(waku utils): Set up default bootstrap node 2024-04-30 19:03:24 +03:00
.github/workflows refactor(ci): Split `Install dependencies` step from `Run tests` 2024-02-29 09:41:31 +02:00
build feat(waku examples): Add examples of pairing with `nwaku` instance 2024-02-12 15:58:15 +02:00
docs docs: Add README 2024-01-13 22:24:59 +02:00
libs/waku_utils feat(waku utils): Set up default bootstrap node 2024-04-30 19:03:24 +03:00
scripts fix(build): Fix build after `nwaku` pkg bump 2024-03-05 11:03:16 +02:00
src feat(waku utils): Set up default bootstrap node 2024-04-30 19:03:24 +03:00
tests chore(build): Use `librln v0.3.7` 2024-04-24 13:07:25 +03:00
vendor chore(vendor): Bump `zerokit` to version `v0.3.7` 2024-04-24 13:07:25 +03:00
.envrc chore(env): Add nix dev env 2024-01-09 15:16:31 +02:00
.gitignore fix(.gitignore): Do not ignore `src/status_node_manager` 2024-03-07 18:40:35 +02:00
.gitmodules config(git): Use `https` in `.gitmodules` 2024-03-05 10:11:53 +02:00
Makefile chore(build): Use `librln v0.3.7` 2024-04-24 13:07:25 +03: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): Bump `nwaku` & `nim-metrics` 2024-03-05 11:03:16 +02:00
status_node_manager.nimble build(nimble): Add `before build` step 2024-03-05 10:11:53 +02:00
status_node_manager.nims build(SNM): Add test `task` and `make command` 2024-03-14 15:40:17 +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.