Description
The e2e infrastructure creates a number of nodes that are executed as a network for testing purposes.
The nodes are created using the default configuration values (from config/config.go), some of which are changed based on parameters provided in the manifest. But if one wants to run an e2e execution using non-standard parameters, there are two possibilities:
- Generate the network/testnet from the manifest, then edit the multiple
config/config.tomlfiles (manually) - Change the defaults values of the same parameters in
config/config.go, which requires re-compiling Comet and producing a new image (i.e., at least 60s)
We should be able to configure in the manifest file for an execution any CometBFT configuration parameter, so that it is applied to the configuration file of all nodes (in the case this setup happens in the general section of the manifest) or specific nodes (in the case this setup happens in the section referring to that specific node).
I can see different ways to implement this feature, but I am open to additional suggestions:
- The
runner, that reads the manifest, should be able to interpret any config parameter used the CometBFT's configuration file. For instance, ifp2p.send_rate = 10000is declared in the general section of the manifest (or in the section of a given node), all nodes (resp., that given node) will have this setup on their configuration file, or at least this setup will override the default parameters in the configuration file. This would be an ideal solution, but I am afraid that it is not simple to implement. - The manifest could contain a flag with a filename, say
comet_config_filepointing to a file that has the same format of traditional config files. The settings in this file would then replace the standards, like in the ordinary execution. This would be the same as creating a defaultconfig.Configthen loading configurations from the provided file, finally dumping the resulting configuration file to the produced home directories used by e2e. This solutions is less practical then the previous, but still much better than what we have now. - This is an option that somehow combines the previous two. We could create a configuration flag, say
comet_config, which can be a field that can contain multiple lines (so, like a file), or a section whose content is interpreted as it was part of Comet configuration. This is pretty similar to 2., the difference is that instead of loading a file, we load a multi-line string parameter or a section, but like option 1. would allow we to keep everything that was customized inside the same manifest file.
Any other ideas are welcome, but I think that having this feature will speed up significantly debugging problems using the e2e infra.