Add minimal list validators

book/src/SUMMARY.md

@@ -14,6 +14,7 @@
 * [Validator Management](./validator-management.md)
     * [The `validator-manager` Command](./validator-manager.md)
         * [Creating validators](./validator-manager-create.md)
+        * [List validators](./validator-manager-list.md)
         * [Moving validators](./validator-manager-move.md)
     * [Slashing Protection](./slashing-protection.md)
     * [Voluntary Exits](./voluntary-exit.md)
@@ -59,6 +60,7 @@
     * [Validator Manager](./help_vm.md)
         * [Create](./help_vm_create.md)
         * [Import](./help_vm_import.md)
+        * [List](./help_vm_list.md)
         * [Move](./help_vm_move.md)  
 * [Contributing](./contributing.md)
     * [Development Environment](./setup.md)

book/src/help_vm.md

@@ -91,6 +91,7 @@ SUBCOMMANDS:
     help      Prints this message or the help of the given subcommand(s)
     import    Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file
               which can be generated using the "create-validators" command.
+    list      List validators of a validator client using the HTTP API. The validators
     move      Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file
               which can be generated using the "create-validators" command. This command only supports validators
               signing via a keystore on the local file system (i.e., not Web3Signer validators).

book/src/help_vm_list.md

@@ -0,0 +1,90 @@
+# Validator Manager List
+
+```
+List validators of a validator client using the HTTP API. The validators
+
+USAGE:
+    lighthouse validator_manager list [FLAGS] [OPTIONS] --vc-token <PATH> --vc-url <HTTP_ADDRESS>
+
+FLAGS:
+        --disable-log-timestamp          If present, do not include timestamps in logging output.
+        --disable-malloc-tuning          If present, do not configure the system allocator. Providing this flag will
+                                         generally increase memory usage, it should only be provided when debugging
+                                         specific memory allocation issues.
+    -h, --help                           Prints help information
+        --log-color                      Force outputting colors when emitting logs to the terminal.
+        --logfile-compress               If present, compress old log files. This can help reduce the space needed to
+                                         store old logs.
+        --logfile-no-restricted-perms    If present, log files will be generated as world-readable meaning they can be
+                                         read by any user on the machine. Note that logs can often contain sensitive
+                                         information about your validator and so this flag should be used with caution.
+                                         For Windows users, the log file permissions will be inherited from the parent
+                                         folder.
+    -V, --version                        Prints version information
+
+OPTIONS:
+    -d, --datadir <DIR>
+            Used to specify a custom root data directory for lighthouse keys and databases. Defaults to
+            $HOME/.lighthouse/{network} where network is the value of the `network` flag Note: Users should specify
+            separate custom datadirs for different networks.
+        --debug-level <LEVEL>
+            Specifies the verbosity level used when emitting logs to the terminal. [default: info]  [possible values:
+            info, debug, trace, warn, error, crit]
+        --genesis-state-url <URL>
+            A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
+            URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
+            be used. If the genesis state is already included in this binary then this value will be ignored.
+        --genesis-state-url-timeout <SECONDS>
+            The timeout in seconds for the request to --genesis-state-url. [default: 180]
+
+        --log-format <FORMAT>
+            Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
+
+        --logfile <FILE>
+            File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
+            new log file is generated where future logs are stored. Once the number of log files exceeds the value
+            specified in `--logfile-max-number` the oldest log file will be overwritten.
+        --logfile-debug-level <LEVEL>
+            The verbosity level used when emitting logs to the log file. [default: debug]  [possible values: info,
+            debug, trace, warn, error, crit]
+        --logfile-format <FORMAT>
+            Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
+
+        --logfile-max-number <COUNT>
+            The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
+            [default: 5]
+        --logfile-max-size <SIZE>
+            The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
+            disabled. [default: 200]
+        --network <network>
+            Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
+            chiado, sepolia, holesky]
+        --safe-slots-to-import-optimistically <INTEGER>
+            Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
+            only be used if the user has a clear understanding that the broad Ethereum community has elected to override
+            this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
+            your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
+        --terminal-block-hash-epoch-override <EPOCH>
+            Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
+            only be used if the user has a clear understanding that the broad Ethereum community has elected to override
+            the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
+            Be extremely careful with this flag.
+        --terminal-block-hash-override <TERMINAL_BLOCK_HASH>
+            Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
+            the user has a clear understanding that the broad Ethereum community has elected to override the terminal
+            PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
+            careful with this flag.
+        --terminal-total-difficulty-override <INTEGER>
+            Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
+            integer (not a hex value). This flag should only be used if the user has a clear understanding that the
+            broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
+            cause your node to experience a consensus failure. Be extremely careful with this flag.
+    -t, --testnet-dir <DIR>
+            Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
+            if there is no existing database.
+        --vc-token <PATH>
+            The file containing a token required by the validator client.
+
+        --vc-url <HTTP_ADDRESS>
+            A HTTP(S) address of a validator client using the keymanager-API. [default: http://localhost:5062]
+```

book/src/validator-management.md

@@ -14,7 +14,7 @@ this document. However, users with more complex needs may find this document
 useful.
 
 The [lighthouse validator-manager](./validator-manager.md) command can be used
-to create and import validators to a Lighthouse VC. It can also be used to move
+to list validators on a Lighthouse VC. Create and import validators to a Lighthouse VC. It can also be used to move
 validators between two Lighthouse VCs.
 
 ## Introducing the `validator_definitions.yml` file

book/src/validator-manager-list.md

@@ -0,0 +1,31 @@
+# List Validators
+
+The `lighthouse validator-manager list` command shows a list of all the validators
+on a validator
+
+## Example
+
+Here we are listing the validators on a Lighthouse VC locally using localhost:
+```bash
+$ l"ighthouse validator-manager list --vc-token ~/data/lighthouse/mainnet/validators/api-token.txt --vc-url http://localhost:5062"
+Running validator manager for mainnet network
+Validator client is reachable at http://localhost:5062/ and reports 3 validators
+  0: ValidatorData { enabled: true, description: "", voting_pubkey: 0xa42c79bb8b...5096432170e281a }
+  1: ValidatorData { enabled: true, description: "", voting_pubkey: 0xa5e8c91eff...c97198a58894e60 }
+  2: ValidatorData { enabled: true, description: "", voting_pubkey: 0xafa1b94d2a...ba4276802c2bd3c }
+  3: ValidatorData { enabled: true, description: "", voting_pubkey: 0xb93730fea6...0769883f8fde6f2 }
+```
+
+But assuming the Lighthouse VC is available on your local network and you've copied the api-token
+to the device your issuing the `list` command from, then you can also list via its IP address.
+```bash
+$ lighthouse vm list --vc-token ~/api-tokens/192.168.1.12-api-token.txt --vc-url http://192.168.1.12:5062"
+Running validator manager for mainnet network
+Validator client is reachable at http://localhost:5062/ and reports 3 validators
+  0: ValidatorData { enabled: true, description: "", voting_pubkey: 0xa42c79bb8b...5096432170e281a }
+  1: ValidatorData { enabled: true, description: "", voting_pubkey: 0xa5e8c91eff...c97198a58894e60 }
+  2: ValidatorData { enabled: true, description: "", voting_pubkey: 0xafa1b94d2a...ba4276802c2bd3c }
+  3: ValidatorData { enabled: true, description: "", voting_pubkey: 0xb93730fea6...0769883f8fde6f2 }
+```
+
+> Note: as a shortcut you can refer to the `validator-manager` using `vm` as seen above.

scripts/cli.sh

@@ -28,6 +28,7 @@ vc_cli=$($CMD vc --help)
 vm_cli=$($CMD vm --help)
 vm_cli_create=$($CMD vm create --help)
 vm_cli_import=$($CMD vm import --help)
+vm_cli_list=$($CMD vm list --help)
 vm_cli_move=$($CMD vm move --help)
 
 general=./help_general.md
@@ -37,6 +38,7 @@ am=./help_am.md
 vm=./help_vm.md
 vm_create=./help_vm_create.md
 vm_import=./help_vm_import.md
+vm_list=./help_vm_list.md
 vm_move=./help_vm_move.md
 
 # create .md files
@@ -46,6 +48,7 @@ write_to_file "$vc_cli" "$vc" "Validator Client"
 write_to_file "$vm_cli" "$vm" "Validator Manager"
 write_to_file "$vm_cli_create" "$vm_create" "Validator Manager Create"
 write_to_file "$vm_cli_import" "$vm_import" "Validator Manager Import"
+write_to_file "$vm_cli_list" "$vm_list" "Validator Manager List"
 write_to_file "$vm_cli_move" "$vm_move" "Validator Manager Move"
 
 #input 1 = $1 = files; input 2 = $2 = new files

validator_manager/src/lib.rs

@@ -5,10 +5,10 @@ use environment::Environment;
 use serde::Serialize;
 use std::path::PathBuf;
 use types::EthSpec;
-
 pub mod common;
 pub mod create_validators;
 pub mod import_validators;
+pub mod list_validators;
 pub mod move_validators;
 
 pub const CMD: &str = "validator_manager";
@@ -44,6 +44,7 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
         .about("Utilities for managing a Lighthouse validator client via the HTTP API.")
         .subcommand(create_validators::cli_app())
         .subcommand(import_validators::cli_app())
+        .subcommand(list_validators::cli_app())
         .subcommand(move_validators::cli_app())
 }
 
@@ -69,6 +70,9 @@ pub fn run<'a, T: EthSpec>(matches: &'a ArgMatches<'a>, env: Environment<T>) ->
                     (import_validators::CMD, Some(matches)) => {
                         import_validators::cli_run(matches, dump_config).await
                     }
+                    (list_validators::CMD, Some(matches)) => {
+                        list_validators::cli_run(matches, dump_config).await
+                    }
                     (move_validators::CMD, Some(matches)) => {
                         move_validators::cli_run(matches, dump_config).await
                     }

validator_manager/src/list_validators.rs

@@ -0,0 +1,91 @@
+use super::common::*;
+use crate::DumpConfig;
+use clap::{App, Arg, ArgMatches};
+use eth2::SensitiveUrl;
+use serde::{Deserialize, Serialize};
+use std::path::PathBuf;
+
+pub const CMD: &str = "list";
+pub const VC_URL_FLAG: &str = "vc-url";
+pub const VC_TOKEN_FLAG: &str = "vc-token";
+
+pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
+    App::new(CMD)
+        .about("List validators of a validator client using the HTTP API. The validators")
+        .arg(
+            Arg::with_name(VC_URL_FLAG)
+                .long(VC_URL_FLAG)
+                .value_name("HTTP_ADDRESS")
+                .help("A HTTP(S) address of a validator client using the keymanager-API.")
+                .default_value("http://localhost:5062")
+                .required(true) // Not actually required but I want it to show up in Usage
+                .requires(VC_TOKEN_FLAG)
+                .takes_value(true),
+        )
+        .arg(
+            Arg::with_name(VC_TOKEN_FLAG)
+                .long(VC_TOKEN_FLAG)
+                .value_name("PATH")
+                .help("The file containing a token required by the validator client.")
+                .takes_value(true),
+        )
+}
+
+#[derive(Clone, PartialEq, Debug, Serialize, Deserialize)]
+pub struct ListConfig {
+    pub vc_url: SensitiveUrl,
+    pub vc_token_path: PathBuf,
+}
+
+impl ListConfig {
+    fn from_cli(matches: &ArgMatches) -> Result<Self, String> {
+        Ok(Self {
+            vc_url: clap_utils::parse_required(matches, VC_URL_FLAG)?,
+            vc_token_path: clap_utils::parse_required(matches, VC_TOKEN_FLAG)?,
+        })
+    }
+}
+
+pub async fn cli_run<'a>(
+    matches: &'a ArgMatches<'a>,
+    dump_config: DumpConfig,
+) -> Result<(), String> {
+    let config = ListConfig::from_cli(matches)?;
+    if dump_config.should_exit_early(&config)? {
+        Ok(())
+    } else {
+        run(config).await
+    }
+}
+
+async fn run<'a>(config: ListConfig) -> Result<(), String> {
+    let ListConfig {
+        vc_url,
+        vc_token_path,
+    } = config;
+
+    let (http_client, _keystores) = vc_http_client(vc_url.clone(), &vc_token_path).await?;
+
+    let response = match http_client.get_lighthouse_validators().await {
+        Ok(response) => response,
+        Err(e) => {
+            println!("Error = {e:?}");
+            return Err(format!("Failed to list validators: {:?}", e));
+        }
+    };
+    for (i, validator) in response.data.into_iter().enumerate() {
+        println!("{i:3}: {validator:?}");
+    }
+
+    Ok(())
+}
+
+// The tests use crypto and are too slow in debug.
+#[cfg(not(debug_assertions))]
+#[cfg(test)]
+pub mod tests {
+    //use super::*;
+
+    #[tokio::test]
+    async fn test_nothing_atm() {}
+}