Add default configuration values #316
Conversation
Address issue letsencrypt#297
|
I imagine this needs some more work but I thought it was a good place to start. |
There was a problem hiding this comment.
Thanks for putting this together! This is really solid. My three in-line comments are about ways to improve this current approach; I also have a different approach to propose which I believe would address all of them:
- Move /test/config/pebble-config.json to /test/config/default-config.json
- Define a const string which is "/test/config/default-config.json"
- Use that const string as the default value of the -config flag
- Have the getDefaultConfig method simply read that config file
That way the default values don't have to be duplicated in two places (and in two formats).
cmd/pebble/main.go
Outdated
| @@ -29,6 +29,17 @@ type config struct { | |||
| } | |||
| } | |||
|
|
|||
| func setConfigDefaults() (config) { | |||
There was a problem hiding this comment.
nit: because this is creating a new config object, rather than setting values on a pre-existing config object, I'd call it getDefaultConfig rather than setConfigDefaults.
There was a problem hiding this comment.
That's what you get for not updating your function names when you change what it does 🤦
cmd/pebble/main.go
Outdated
| conf.Pebble.PrivateKey = "test/certs/localhost/key.pem" | ||
| conf.Pebble.HTTPPort = 5002 | ||
| conf.Pebble.TLSPort = 5001 | ||
| return conf |
There was a problem hiding this comment.
There are two values (ocspResponderUrl and externalAccountBindingRequired) which don't get initialized here. Sure, their defaults are also their zero-values, but being explicit is good.
cmd/pebble/main.go
Outdated
| @@ -29,6 +29,17 @@ type config struct { | |||
| } | |||
| } | |||
|
|
|||
| func setConfigDefaults() (config) { | |||
| var conf config | |||
| conf.Pebble.ListenAddress = "0.0.0.0:14000" | |||
There was a problem hiding this comment.
Add a comment showing readers that these values are identical to the values in /test/config/pebble-config.json, and that they should be kept in sync.
|
I was wondering whether it was better to read the defaults from a file. Should I fix up this PR or open a new one? |
|
I'd go ahead and keep using this one -- we just ask that you update it by pushing additional commits, not by rewriting and then force-pushing. If you'd rather start over from scratch, opening a new one is fine too! Doesn't matter much on our end :) |
Co-authored-by: Aaron Gable <aaron@aarongable.com>
I'm not sure whether it is a good idea to expect the file |
I could swap the |
|
I personally would explicitly set the values (as in a previous version of the PR), and remove all values having the default settings from the test config files. That's pretty much incompatible to what @aarongable wrote though :) |
|
It's not wholly incompatible -- it's fine with me if the default values are only specified in code and the default config JSON doesn't exist at all. My primary goal is that they not be specified in two places (and therefore have to be kept in sync). I just think that that solution is likely to be more confusing in the long run, as it is less "self-documenting" for consumers who do want to change values. But if it has other material advantages -- for example, not requiring the default-config.json file to exist at all -- then it is worth considering. |
|
How about having the defaults baked in and command line flags to change them? |
|
I'd prefer not to change the CLI of pebble at this time. A change like this imo isn't worth an API-breaking change; sticking with the existing One possibility here would be for |
If default config exists try to read it into the config structure else return a blank config.
|
I'm not sure that I agree that it is a breaking change -- the behavior when no flags are passed is identical, and when specific flags are passed, it is the user's responsibility to ensure that those flags are good. Happy to be convinced otherwise, though. That said, in order to correctly change the file to default-config.json, the README.md and docker-compose.yml also need to be updated. |
Address issue #297