[RFC] Standardized viper framework for vitess configuration parameters#11456
[RFC] Standardized viper framework for vitess configuration parameters#11456ajm188 merged 100 commits intovitessio:mainfrom
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
If a new flag is being introduced:
If a workflow is added or modified:
Bug fixes
Non-trivial changes
New/Existing features
Backward compatibility
|
mattlord
left a comment
There was a problem hiding this comment.
I like it! I only had a few very minor questions.
doc/viper/viper.md
Outdated
There was a problem hiding this comment.
@mattlord absolutely not urgent, but curious if you have any strong reactions (positive or negative!) to the 2(and a half) approaches outlined here
I'm gonna noodle on this in the background but broadly turn my attention today to working out how to best use config files (also, if you have any good examples of configs that we would want to be dynamic (query timeouts, and other "threshold-y" type things, probably?) let me know!
There was a problem hiding this comment.
https://github.com/vitessio/vitess/blob/main/go/vt/vttablet/tabletserver/debugenv.go
https://github.com/vitessio/vitess/blob/main/go/vt/vtgate/debugenv.go
Those are the things that can be changed at runtime as of today.
b3c61a0 to
f952af6
Compare
|
First comment is that we need an issue with a task breakdown! |
9788a28 to
1a13f9f
Compare
(it's empty now, but! 😂) I'll be putting in details here as I go! |
There was a problem hiding this comment.
TODOs:
Other more general merge-blocking TODOs:
- fill out issue with more details
- update local example (at least, do the operator later) to demonstrate file-based configs
- at least attempt (but do not include in this change) a dynamic Value to power either vtgate's or vttablet's debugenv to make sure the API works well/ergonomically
go/vt/topo/locks.go
Outdated
There was a problem hiding this comment.
Will each module that supports dynamic configuration have to (need to?) write such a block of code? Or will it (can it?) be delegated to a helper that can take some metadata and callback?
There was a problem hiding this comment.
you would need to write your own code to consume the update notifications (if you want to do something like "log when the value changes" or "only check at most N seconds for a new value otherwise use the previous value").
if you want to just always take the current value in the config file (and also always pay the potential cost of the RWMutex), you can just call myValue.Get().
i think if we tried to create a single helper for this, it would be extremely tricky to support every use case (or turn into a mess of spaghetti code as we add edge case after edge case 😂)
There was a problem hiding this comment.
I think we should always be calling myValue.Get() unless there is a very good reason to only poll periodically.
There was a problem hiding this comment.
strongly agree that should be the (rare) exception, and not the norm
8aac968 to
91689f1
Compare
|
I have looked through the doc. Looks good to me |
go/viperutil/funcs/decode.go
Outdated
There was a problem hiding this comment.
Going to file an issue to follow up on this one, as it'll involve some more moving stuff around
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Co-authored-by: Matt Lord <mattalord@gmail.com> Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
| fs.StringVar(&containerName, "azblob_backup_container_name", "", "Azure Blob Container Name.") | ||
| fs.StringVar(&storageRoot, "azblob_backup_storage_root", "", "Root prefix for all backup-related Azure Blobs; this should exclude both initial and trailing '/' (e.g. just 'a/b' not '/a/b/').") | ||
| fs.IntVar(&azBlobParallelism, "azblob_backup_parallelism", 1, "Azure Blob operation parallelism (requires extra memory when increased).") | ||
| fs.String("azblob_backup_account_name", accountName.Default(), "Azure Storage Account name for backups; if this flag is unset, the environment variable VT_AZBLOB_ACCOUNT_NAME will be used.") |
There was a problem hiding this comment.
All this looks great.
Wondering if we could further simplify this by allowing a FlagDesc atrribute to viperutil.Configure so that we could just call a helper viperutil.BindAndRegisterAllFlags(configKeyPrefix) . We already specify the types, flag names and defaults in Configure().
There was a problem hiding this comment.
I wanted that so badly, the issue is it's very hard to generalize the underlying function calls to pflag.{String,Int,...}Var and pflag.Var
Signed-off-by: Andrew Mason andrew@planetscale.com
Description
This PR outlines, in docs and working code, a framework for a standardized way of interacting with viper to power configuration parameters for all Vitess binaries. (the docs also try to provide some context as to why we want to introduce a framework like this).
Please feel free to comment, ask questions, poke holes, etc and just generally provide feedback on the approach. We can then (pending changes that come up during the RFC period) merge this in and start moving modules to use this approach to take their configurations from places other than command-line flags.
Related Issue(s)
#11788
Checklist
Deployment Notes