Go-ipfs: `ipfs config` and live daemon configuration state

[massino]

Version information:

go-ipfs version: 0.4.11-
Repo version: 6
System version: amd64/darwin
Golang version: go1.9

Type:

Bug

Severity:

Low

Description:

ipfs config interacts with the configuration file on disk, but not with the current configuration state of the daemon. This means that the operator cannot know for sure which configuration is currently applied, and which requires a daemon restart.

Below are a few possible ways to fix the issue.

1. Add an optional flag ipfs config [--live=false]. On --live=true, all config commands operate on the live config state of the running daemon, instead of the config file.

2. Add a new command ipfs config reload, to reload the live configuration from disk without requiring a daemon restart.

3. Add a new command ipfs config diff, to show the differences between the live configuration and the on-disk configuration. Optionally, this could be implemented as ipfs config reload --dry-run.

[bobheadxi]

@kevina @massino is there any update on this, and if not, is there a better alternative to updating the configuration other than an ipfs shutdown + ipfs daemon? Thanks!

[Stebalien]

Unfortunately, there's no update for now. This would be a great feature to have but likely won't happen for a while.

[bobheadxi]

@Stebalien thanks for the quick response!

We (RTradeLtd) are interested in implementing this - if you have any pointers for how we might go about it, it would be greatly appreciated!

[magik6k]

There are (al teast) 2 ways to approach this:

• Restart node internally, running entire setup again
  
  
  
  • Interrupts all running requests (or wait for their completion without allowing new requests, but that becomes really hard really fast)
  
  
  • Likely quite slow, but still better than ipfs shutdown + ipfs daemon
  
  
• 
  
  1. Apply config changes as to node too, without restarts
  
  
  2. Much harder to get right:
  
  
  3. All settings need to know how to affect node state
  
  
  4. There is a lot of non-obvious dependencies, subsystems hold references to other subsystems which only touched config at construction time
  
  
  5. Much more invasive than just restarting the node, so will need much more testing
  
  
  6. Needs to be atomic (a big problem with how IpfsNode is currently designed and used)
  
  
  7. But it may be faster and in some cases we don't have to care about in-flight requests
  
  

First option should be fairly easy to implement, second would need to be implemented very carefully and require a lot of invasive changes in the codebase (I'm planning IpfsNode refactor, I'll try to take this into account)

[bobheadxi]

Thanks @magik6k - I think we're interested in implementing the second one, since if we're going to do it, we might as well go all the way right?

A bit curious about your planned IpfsNode refactor, however - is this something that you'll be working on soon? We don't want to clash with your work, so should we wait, or work together with you on the refactor?

[magik6k]

It depends on your definition of 'soon', but probably no. I'm just lining up ideas for how to make it better, but it will happen somewhere in 2019 when coreapi stabilizes.

If you really want to start working on it, I'd start with creating a meta issue documenting all config options, whether they are applied live (some already are), and what is required to make this happen. Then with some discussion you and maybe some other contributors should be able to jump in and make the changes in smaller chunks so PRs don't take months to review and are simpler in general.

cc @Stebalien

[Stebalien]

The second option shouldn't actually be that tricky. We'd probably want to:

1. Make it possible to subscribe to configuration changes.
2. When an ipfs config reload is issued, all subscribers would get a copy of the old config and the new config.
3. Internally, commands would always see the old config until a reload is requested.

Ideally, services would be able to subscribe to portions of the config but that's probably more trouble than it's worth.