Live changes to neard - how should it work?

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.

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?

Prior art: we already support dynamic config for logging:

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;
            
             },
        
      
    

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.

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.