Redesign application config command

[Tschakki]

Description

The configuration of Lisk Core is confusing and cumbersome in certain regards

• There is no great template for creating custom configuration files: The default network configuration files are not including all available config options. There should be a config template, including all existing config options and their default values, so it can be adjusted as required, without further investigation efforts.
• It is not possible to verify which configuration is actually used in Lisk Core: The configuration in ~/.lisk/lisk-core/config/ is not updated with the config actually used, for example, when specifying a custom config with the --config/-c flag. Also, the command lisk-core config:show is not showing the config actually used by Lisk Core, when a custom config is used, which makes the command not helpful, and even worse, it is returning a configuration not used at all, and is therefore additionally confusing and misleading.
• As an effect, it is also confusing when to use the --overwrite-config flag, because it cannot be verified what is actually overwritten. Also, imho it is the default case that you want to override the existing config if you start Core with different config values. So i personally don't see the point of having this flag, and overwriting the config should be rather the default behaviour for starting Lisk Core with custom flags and/or config.

Motivation

Configuration of Lisk Core creates unnecessary headaches and obstacles.

Additional Information

[Nazgolze]

I'm 99% onboard, but want to get into the last bullet point a little. "The devil is in the details" as they say.

Also, imho it is the default case that you want to override the existing config if you start Core with different config values

:100:%, but...

So i personally don't see the point of having this flag, and overwriting the config should be rather the default behaviour for starting Lisk Core with custom flags and/or config

Overriding and overwriting - the difference is that 'overwrite' here will overwrite and replace the config stored in ~/.lisk/lisk-core/config, and it will overwrite it with the default values, not the custom config, even if a custom config is specified (it's not how I would expect it). I think that's something that should be explicitly specified by the user with --overwrite-config and not happen by default. As to when a user might want to use it, I've only used it when switching networks to delete my old settings, but maybe there are other scenarios. I can see where the confusion comes from, I wonder if there's a better way

[shuse2]

We will look into how config is handled in other projects/products, and plan better solution.

This config redesign should consider the problem about large genesis block. Since large genesis block cannot be passed between application and engine, we need to consider adding path to the genesis block in the config. Also, for debugging, it would be nice to add a path to generator keys so that engine can initialize the generator keys without RPC call.

[shuse2]

Closing this issue for no activity