Live changes to neard - how should it work?

mm-near · October 20, 2022, 2:21pm

There are more and more use cases that would benefit from being able to ‘live-change’ the running neard binary (from enabling/disabling debug, changing number of peers, planning a shutdown at a given height etc etc).

There are 3 approaches that we’re considering, and we’re curious for the community feedback (especially from people who are running validator nodes).

create ‘dynamic-config.json’ file – that would live next to ‘config.json’. And it would be read either on each change, or when process receives signal.
open a separate port - to which you could send RPC requests that would modify the config.
add another ‘path’ to the :3030 port (same way how we have a ‘debug’ path there) - and have RPC served there.

The changes that can be done via this API will BE DANGEROUS - so we want to make sure that we pick the method that is easiest for you to secure.

SamLegends · October 20, 2022, 4:11pm

I haven’t used the blacklist feature, but we had an issue on another chain were that would have been helpful.

Any chance of swapping keys in real time?

matklad · October 20, 2022, 4:12pm

Prior art: we already support dynamic config for logging:

github.com

near/nearcore/blob/19bbc61a0e0d7c9dcad6c51c1bd8d24ae7390d47/neard/src/cli.rs#L466-L489

      
        
            #[cfg(unix)]
            async fn wait_for_interrupt_signal(home_dir: &Path, mut rx_crash: Receiver<()>) -> &str {
                let watched_path = home_dir.join("log_config.json");
                let log_config_watcher = LogConfigWatcher { watched_path };
                // Apply the logging config file if it exists.
                log_config_watcher.update(UpdateBehavior::UpdateOnlyIfExists);
            
            
    use tokio::signal::unix::{signal, SignalKind};
                let mut sigint = signal(SignalKind::interrupt()).unwrap();
                let mut sigterm = signal(SignalKind::terminate()).unwrap();
                let mut sighup = signal(SignalKind::hangup()).unwrap();
            
            
    loop {
                    break tokio::select! {
                         _ = sigint.recv()  => "SIGINT",
                         _ = sigterm.recv() => "SIGTERM",
                         _ = sighup.recv() => {
                            log_config_watcher.update(UpdateBehavior::UpdateOrReset);
                            continue;
                         },

This file has been truncated. show original

mm-near · October 28, 2022, 2:11pm

If we had mechanism like this, then things like swapping keys (I assume you’re talking about the validator keys?) would be technically possible.

(But there are some other considerations - from message routing, to approval heights etc).
If this is something that you’re interested in - let’s create a separate topic and we can discuss the details there.

mm-near · October 28, 2022, 2:12pm

Ok - as there were no strong suggestions or preferences over the last week - I’d suggest going with the option that @matklad mentioned – having a separate config file that would be read when process receives a signal.

Topic		Replies	Views
Store protocol config in a contract Development	6	588	July 6, 2021
New NEAR CLI design proposal! Proposals	17	1689	August 9, 2021
2021-05-24 Engineering Update Engineering Updates weekly-updates	0	476	May 24, 2021
[Report January] Near peer to peer (P2P) DaPP NEAR-DEx (January 03 - January 28 - 2022) Learning Products community , near , guild-reports	0	330	January 29, 2022
[PROPOSAL] Limited replayability / Limited past protocol version support in neard Proposals	8	375	December 12, 2022

Live changes to neard - how should it work?

Related topics