env vars (e.g. MINA_LIBP2P_PASS=super_secret mina ...
Proposal to Remove Compile Time Config
The compiled configuration is the most problematic of all of these:
It's not always known in advance how you want to use a binary (this is the reason for configuration in the first place)
The configuration mismatches caused by running a binary with the "wrong" file is extremely confusing/misleading (e.g. --profile=dev but running with --config-file genesis_ledgers/mainnet.json). @svv232 and I spent a lot of time fixing problems caused by this when we were getting started.
It forks the releases in unnecessary ways -- currently it can happen that you would cut 9 different releases for the "same" binary (3 different debian bases x 3 different build profiles).
It's generally considered best practice to not use compile time configuration. I have already done some work estimating how much of this we actually use, and it's really not that bad. See #15781 for a list of unused config that we could delete immediately.
Proposal to remove "fallback" searches for missing configuration
I noticed that some configuration options come with several "fallback" strategies. It's kind of an antipattern imo -- as the operator I would expect a precise value to be determined either via a "sensible default" or if there is no sensible default, you should require me to give you the configuration directly. This was a pretty big foot gun when the daemon searches for the genesis ledger in multiple places, e.g.
let possible_paths base =
List.map
[ env_path
; brew_install_path
; s3_install_path
; autogen_path
; manual_install_path
] ~f:(fun d -> d ^/ base)
When allowed to search in multiple places, you might pick the wrong one (which is exactly what happened). There may be other places people know of where we do this.
Proposal to document the configuration guidelines
If we're gonna eliminate compiled config, we need to place those options in one of the 3 other buckets listed. Personally I think 3 is too many (e.g. can we get away with env vars only? env vars + cli args?). Ideally guidelines should reflect easy deployment strategies and also ease of local development.
The mina binary use a hybrid of configuration embedding methods:
*.mlh) files (e.g../config/dev.mlhviadune --profile=dev)genesis_ledgers/devnet.json)mina daemon --metrics-port blah)env vars (e.g.
MINA_LIBP2P_PASS=super_secret mina ...Proposal to Remove Compile Time Config
The compiled configuration is the most problematic of all of these:
--profile=devbut running with--config-file genesis_ledgers/mainnet.json). @svv232 and I spent a lot of time fixing problems caused by this when we were getting started.It's generally considered best practice to not use compile time configuration. I have already done some work estimating how much of this we actually use, and it's really not that bad. See #15781 for a list of unused config that we could delete immediately.
Proposal to remove "fallback" searches for missing configuration
I noticed that some configuration options come with several "fallback" strategies. It's kind of an antipattern imo -- as the operator I would expect a precise value to be determined either via a "sensible default" or if there is no sensible default, you should require me to give you the configuration directly. This was a pretty big foot gun when the daemon searches for the genesis ledger in multiple places, e.g.
When allowed to search in multiple places, you might pick the wrong one (which is exactly what happened). There may be other places people know of where we do this.
Proposal to document the configuration guidelines
If we're gonna eliminate compiled config, we need to place those options in one of the 3 other buckets listed. Personally I think 3 is too many (e.g. can we get away with env vars only? env vars + cli args?). Ideally guidelines should reflect easy deployment strategies and also ease of local development.