Add ADR for checking node configuration files with cardano-cli

[smelc]

ADR explaining how we came up with the CLI's check-node-configuration command.

I've left the various commits to allow reviewers to see the decision's history, but I will squash before merging.

[carbolymer]

Can you highlight more status quo here?

[smelc]

In the end I didn't, because the scope changed: we only check the configuration file, we don't create it.

[Jimbo4350]

I don't think we should have a command to create a node configuration file as we will be repeating ourselves in a sense (why not just create the config file to begin with?). On the other hand a command that checks a node config file for the user would be handy. For example:

• The files listed do exist (and can be successfully decoded?)
• The mandatory configuration values are set

[Jimbo4350]

Why list the options again? It should just check the existence of filepaths and that the genesis file hashes are correct. Have a look at the other fields that it may make sense to have checks for as well but to re-enter the file paths doesn't make sense imo. Parameterizing it on the era makes sense because things can change era to era and notifying the user what they may be missing in an upcoming era would be useful.

[smelc]

Yes, actually this was an earlier design and the actual WIP work (this branch) has the following API:

cardano-cli debug check-node-configuration
  --node-configuration-file FILEPATH
  [--fix-configuration-file]

Updating the ADR accordingly right now 👍

[Jimbo4350]

👍

[carbolymer]

Can you describe the risks and who is affected by not checking the configuration file?
I see that you described it in the Consequences, but I think it belongs more to the Context.

[smelc]

Good point 👍

Adding more details in the Context section:

 # Context
 
-There is no way to check a node configuration file for basic sanity issues.
+There is no way to check a node configuration file for basic sanity issues. This is a problem for people running testnets, because they will only discover _after having started their testnet_ that something is wrong (because the node will refuse to start). And starting a testnet is a costly operation, meaning the failures will only happen after tenth of seconds; causing the feedback loop to be slow.

[carbolymer]

I would avoid listing the command names and option names. Those are parts of the user interface design, and not really n part of an architecture. Additionally, the commands and option names can change during the time and the ADR will be out of sync.

If you insist on keeping the command and option names, can you rephrase the text to make them examples rather than a references to a command option / toggle?
For example instead of

Have a --fix flag

We considered having a --fix flag that would make check-node-configuration:

write

Provide fix up capability

We considered having a dedicated flag (e.g. --fix) that would make the command:

[smelc]

@carbolymer> good point 👍

I addressed your concerns in the additional commit Do not give exact API in the ADR. Make it more high-level.

[carbolymer]

I'm ok with this. 👍🏻

I remember there was a brief discussion about parsing of node config files, where the datatypes should lie and what's the difference between the cardano-node parsing of config file and what's done in api/cli. If there were conclusions, they would be worth adding here I think.