Usability: command-line options for node configuration

[mzabaluev]

Tracking issue: #481

Currently, node configuration is obtained from environment variables.
A system based on configuration files is discussed in #384, but we can also consider making some node settings configurable via command-line options.

[l-monninger]

I think we should use the following hierarchy in pseudo-JavaScript:

cliArgument ?? configFileField ?? environmentVariable ?? defaultValue;

[l-monninger]

Atlantis is a good example of this: https://www.runatlantis.io/docs/server-configuration

[mzabaluev]

Yes, this is pretty conventional, for example git follows this hierarchy.

[l-monninger]

I believe this is ready for an issue.

[mzabaluev]

Should we come up with a list of options that make sense to be overridable in the command line?
I'd like to identify use cases that are important to:

1. Node operators.
2. Developers of tests.

A less customer-driven approach can be also taken: anything that does not have a sensible default should be settable with a CLI option (overriding the other configuration sources listed in another comment).

[l-monninger]

I agree, these are the main cases.

anything that does not have a sensible default

I kind of think we should strive to design our systems s.t. there is always a sensible default--at least assuming a particular running mode is applied elsewhere.

[mzabaluev]

Proposed options for suzuka-full-node:

• Chain ID (as --chain-id).
• DA light node URL (as --da-light-node).
• Location of the secrets file providing e.g. the executor private key (as --secrets-file). See the discussion in Framework for managing secrets #387 for other options.

[l-monninger]

Location of the executor private key (as --secrets-file).

This will not be so simple because of considerations in #435 . Really, we will probably want some string format or multiple fields to represent how a structure for signing can be deserialized from CLI args.

[l-monninger]

Are these supposed to be additional options from what is currently provided? I would say we kind of want everything under the current config until we figure out how we want to strip out. For example, a node operator may want to play around with load-shedding parameters and find it easier to do that playing around with the CLI. x

[mzabaluev]

It's difficult to make assumptions without customer input.

My current thinking is to list the options that need to be customized for any deployment, and provide a way to specify locations of some important files.

Perhaps the dot-movement directory path should be a CLI option, too. But it's more natural to think of it as the shared environment for possibly multiple local processes, and it has a well-known default, so it could be a common convention to set it as an environment variable.

[mzabaluev]

Location of the executor private key (as --secrets-file).

This will not be so simple because of considerations in #435 . Really, we will probably want some string format or multiple fields to represent how a structure for signing can be deserialized from CLI args.

Yes, I really mean the secrets file should serialize a structure configuring access to the private keys.
In the simplest form, for purposes of local testing, it will encode a single private key.

[mzabaluev]

Added --da-light-node URL, a moving part in the two-service configuration.

[mzabaluev]

Proposed options for m1-da-light-node:

• Chain ID as --chain-id.
• Celestia RPC URL as --celestia-rpc.
• Celestia Websocket URL as --celestia-websocket.
• Migrations configuration file (see Suzuka DA Migrations Format #470) as --da-migrations.

[mzabaluev]

The migrations could be a well-known file under dot-movement, too.

[l-monninger]

Yes, ultimately, that's how I envision it actually be stored as a file.

[l-monninger]

One thing that we still need to break out is how we want config files to be stored. That is, do we want multiple configs, a single config with a global namespace, etc. There's a single-source of truth vs. modularity tradeoff here.

[mzabaluev]

One thing that we still need to break out is how we want config files to be stored. That is, do we want multiple configs, a single config with a global namespace, etc. There's a single-source of truth vs. modularity tradeoff here.

Yes, this should be discussed on the side of #384.
@l-monninger Should the config location (modulo the decision on whether it's global or service-specific config) be customizable at least? Dot-movement is an easy default solution, but service deployments and filesystem standards on Unix preferred to split configuration from dynamic storage for decades now. With modern immutable container configurations, having the config deployed in a read-only /etc layer may be a requirement.

[mzabaluev]

Broken out as #533.