-
Notifications
You must be signed in to change notification settings - Fork 902
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration rework #6243
Configuration rework #6243
Conversation
If you're not in a hurry, then I would love to delve into this and test it (give me 10days). One question/idea about |
Does it mean we can switch from
Not sure what you mean, but when I run it with IMHO being able to see to which plugin an option belongs to makes everything more understandable. Maybe the |
And finally a little off-topic, it would be nice if users can see more option's default values, it makes everything less obscure. Many build-in plugins based on |
[ Oops, I realized you are looking at the old PR. I hated this one, so I've reworked the format... Fixing tests now! ] Well, since the format is now a dict, it's possible. It's a bit weird though, since it's not really dynamic. |
Yeah, we won't be doing that 🤣 It would be on selected options, which would explicitly opt-in.
That was redundant with Testing now... |
6180cbf
to
99a2a78
Compare
Pushed updated, rebased version, and included more details in PR description! |
580b4a3
to
13df5f3
Compare
Ok looks good, descriptions can easily be added now when desired (I think so). For convenience I did it on this branch, see the last two commits. Perhaps default values can also added to the descriptions, which should be easy for plugin options. |
The problem now is that our descriptions are in several places: the man pages, and the code. We should settle on one place though. The man page is more chatty, which is useful, but probably overkill for the code? Perhaps we should get one line from the code, and paste in the rest of the chatter for the man page. Anyway, I think this is a follow-on from this PR, which I'd like to merge soon. |
Trivial rebase to make --dev-allowdustreserve dev-only in its own commit, rather than a driveby... |
13df5f3
to
69470c1
Compare
Currently it fails if a field is missing, but sometimes that's OK. So allow a fieldname ending in `?` to mean "skip over if it's missing". Signed-off-by: Rusty Russell <[email protected]>
We leave the code in contrib/pyln-client/pyln/client/lightning.py to handle msat null fields for now, though, for a bit more compatibility. Signed-off-by: Rusty Russell <[email protected]>
The new listconfigs fields will be objects, and this messes us up! Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
This adds: 1. ability to search for an option by name. 2. allowance to set our own bits when registering options. 3. show callbacks which can say "don't show", and variable length. Signed-off-by: Rusty Russell <[email protected]>
Now we can look up the name using opt_find_long, we can do that first, simplifying this code. Signed-off-by: Rusty Russell <[email protected]>
…l casing. Note that this actually changes listconfigs output for three msat fields, which were not changed with the great msat merge. Since listconfigs isn't actually used by grpc, and the values are always a little vague, I simply changed this. Changelog-Fixed: JSON-RPC: `listconfigs` `htlc-minimum-msat`, `htlc-maximum-msat` and `max-dust-htlc-exposure-msat` fields are now numbers, not strings. Signed-off-by: Rusty Russell <[email protected]>
These are gathered from the config files and the commandline, but the process is rather complex! We want to remember where the options came from in future (for a `setconfig` command), and also generalize and simplify handling. Signed-off-by: Rusty Russell <[email protected]>
… times. This will be used for listconfig, which knows these should be presented as arrays, not single values. Signed-off-by: Rusty Russell <[email protected]>
Otherwise, we should rename it? Signed-off-by: Rusty Russell <[email protected]>
This is a nod towards moving to runtime-developer-mode, and also quite clear; we currently have all these options prefixed with dev, but this flags makes handling explicit. Signed-off-by: Rusty Russell <[email protected]>
69470c1
to
5dadbb1
Compare
Rebased on master to resolve simple conflicts. |
Now we wire in the code which gathers configvars and parses from there; lightningd keeps the array of configuration variables for future use. Note that lightning-cli also needs to read the config, but it has its own options (including short ones!) and doesn't want to use this configvar mechanism, so we have a different API for that now. Signed-off-by: Rusty Russell <[email protected]>
Developers, rejoice (we already have --testnet, --signet and --mainnet!). Changelog-Added: Config: `--regtest` option as alias for `--network=regtest` Signed-off-by: Rusty Russell <[email protected]>
It's an obscure command, but this we won't see old plugin commands in listconfigs (once it uses configvars). Signed-off-by: Rusty Russell <[email protected]>
Clearly, listconfigs shouldn't list these. Also, hoist the opt_hidden check since it's independent of whether there's an arg or not. Signed-off-by: Rusty Russell <[email protected]>
We have hacky code to show some listconfigs values as literals; instead explicitly encode the types. Signed-off-by: Rusty Russell <[email protected]>
It literally contained \" to avoid it being interpreted as a literal; now we have OPT_SHOWINT we no longer need this hack. It's obscure, so I'm not bothering with a deprecation cycle. Changelog-Fixed: JSON-RPC: `listconfigs` `rpc-file-mode` no longer has gratuitous quotes (e.g. "0600" not "\"0600\""). Signed-off-by: Rusty Russell <[email protected]>
listconfigs is convenient, but it doesn't handle multi-options well: it outputs an object with duplicate fields in this case (e.g. log-file), nor is it extensible to show more than raw values. However, listconfigs doesn't do what other list commands do (use a sub-object "configs") so we can put the new values under that. Signed-off-by: Rusty Russell <[email protected]> Changelog-Added: JSON-RPC: `listconfigs` now has `configs` subobject with more information about each config option.
Changelog-Deprecated: Plugins: `default` no longer accepted on `flag` type parameters (it was silently ignored, so just don't set it). Signed-off-by: Rusty Russell <[email protected]>
We use multi-specifiable options elsewhere, this is just another. Otherwise you can't add, you can only set them all. Changelog-Added: Config: `accept-htlc-tlv-type` (replaces awkward-to-use `accept-htlc-tlv-types`) Changelog-Deprecated: Config: `accept-htlc-tlv-types` (use `accept-htlc-tlv-type` multiple times) Signed-off-by: Rusty Russell <[email protected]>
This integrates them with configvars properly: they almost "just work" in listconfigs now, and we don't put them in a special sub-object under their plugin. Unfortunately, this means `listconfigs` now has a loose schema: any plugin can add something to it. Signed-off-by: Rusty Russell <[email protected]> Changelog-Fixed: Plugins: reloaded plugins get passed any vars from configuration files. Changelog-Deprecated: Config: boolean plugin options set to `1` or `0` (use `true` and `false` like non-plugin options).
Use the configs object, as the others are about to be deprecated. Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Changelog-Deprecated: JSON-RPC: `listconfigs` direct fields, use `configs` sub-object and `set`, `value_bool`, `value_str`, `value_int`, or `value_msat` fields. Signed-off-by: Rusty Russell <[email protected]>
I chose the full path name, not just the basename. Suggested-by: @SimonVrouwe Signed-off-by: Rusty Russell <[email protected]>
5dadbb1
to
23a5199
Compare
Rebase to fix trivial error for liquid tests (assuming network=regtest in msg) |
opt_register_early_noarg("--regtest", | ||
opt_set_specific_network, "regtest", | ||
"Alias for --network=regtest"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I the only one who dislikes aliased options? --network=regtest
== --regtest
😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm split. I hate the redundancy, but love the brevity...
To make room for a future
config
command to dynamically set configuration variables, I had to delve into our configuration subsystem. It took far longer than I'd expected, but here is the result.Concretely:
configs
sub-object: each value in here is a dict, including source, and type information.I apologize for the scope of this: configuration is hard and I tried not to break anything.
Fixes: #5294
Example output: