-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[RFC] Standardized viper framework for vitess configuration parameters #11456
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
|
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 like it! I only had a few very minor questions.
doc/viper/viper.md
Outdated
|
||
Broadly speaking, there's two approaches for Vitess to using viper. | ||
|
||
### Approach 1: Everything in the global registry. |
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODOs:
- [RFC] Standardized viper framework for vitess configuration parameters #11456 (comment)
- [RFC] Standardized viper framework for vitess configuration parameters #11456 (comment)
- [RFC] Standardized viper framework for vitess configuration parameters #11456 (comment)
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
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.
Nice write-up. Looks like they're a bunch of TODOs. We can get this reviewed at the code level once those are resolved.
go/vt/topo/locks.go
Outdated
@@ -66,10 +76,29 @@ func init() { | |||
for _, cmd := range FlagBinaries { | |||
servenv.OnParseFor(cmd, registerTopoLockFlags) | |||
} | |||
|
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
|
||
// TODO: this creates an import cycle ... IMO tabletenv should not define Seconds, | ||
// it should be in something more akin to flagutil with the other values like | ||
// TabletTypeFlag and friends. |
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.
Agreed
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.
Going to file an issue to follow up on this one, as it'll involve some more moving stuff around
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.
Signed-off-by: Andrew Mason <andrew@planetscale.com>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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