Skip to content
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

Merged
merged 100 commits into from
May 25, 2023

Conversation

ajm188
Copy link
Contributor

@ajm188 ajm188 commented Oct 9, 2022

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

  • "Backport me!" label has been added if this change should be backported
  • Tests were added or are not required
  • Documentation was added or is not required

Deployment Notes

@vitess-bot
Copy link
Contributor

vitess-bot bot commented Oct 9, 2022

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

  • Ensure that the Pull Request has a descriptive title.
  • If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
  • If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

  • Is it really necessary to add this flag?
  • Flag names should be clear and intuitive (as far as possible)
  • Help text should be descriptive.
  • Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

  • Each item in Jobs should be named in order to mark it as required.
  • If the workflow should be required, the maintainer team should be notified.

Bug fixes

  • There should be at least one unit or end-to-end test.
  • The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

  • There should be some code comments as to why things are implemented the way they are.

New/Existing features

  • Should be documented, either by modifying the existing documentation or creating new documentation.
  • New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

  • Protobuf changes should be wire-compatible.
  • Changes to _vt tables and RPCs need to be backward compatible.
  • vtctl command output order should be stable and awk-able.
  • RPC changes should be compatible with vitess-operator
  • If a flag is removed, then it should also be removed from VTop, if used there.

Copy link
Contributor

@mattlord mattlord left a 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.

go/trace/plugin_datadog.go Outdated Show resolved Hide resolved
go/viperutil/viper.go Outdated Show resolved Hide resolved
go/viperutil/viper.go Outdated Show resolved Hide resolved
go/viperutil/viper.go Outdated Show resolved Hide resolved

Broadly speaking, there's two approaches for Vitess to using viper.

### Approach 1: Everything in the global registry.
Copy link
Contributor Author

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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deepthi
Copy link
Member

deepthi commented Nov 18, 2022

First comment is that we need an issue with a task breakdown!

@ajm188 ajm188 added Type: Feature Type: RFC Request For Comment Component: General Changes throughout the code base labels Nov 21, 2022
@ajm188 ajm188 changed the title [WIP] Taking a stab at a way to standardize viper usage [RFC] Standardized viper framework for vitess configuration parameters Nov 21, 2022
@ajm188 ajm188 marked this pull request as ready for review November 21, 2022 19:53
@ajm188
Copy link
Contributor Author

ajm188 commented Nov 22, 2022

First comment is that we need an issue with a task breakdown!

(it's empty now, but! 😂) I'll be putting in details here as I go!

Copy link
Contributor Author

@ajm188 ajm188 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

.golangci.yml Outdated Show resolved Hide resolved
go/flagutil/enum.go Show resolved Hide resolved
go/vt/topo/locks.go Outdated Show resolved Hide resolved
Copy link
Member

@deepthi deepthi left a 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.

doc/viper/viper.md Show resolved Hide resolved
@ajm188
Copy link
Contributor Author

ajm188 commented Nov 29, 2022

Nice write-up. Looks like they're a bunch of TODOs. We can get this reviewed at the code level once those are resolved.

well, at least some of the TODOs (example => this one) can potentially be obviated via code review, so i think at least a first-pass should happen before doing that

@deepthi deepthi requested a review from a team November 29, 2022 20:36
@@ -66,10 +76,29 @@ func init() {
for _, cmd := range FlagBinaries {
servenv.OnParseFor(cmd, registerTopoLockFlags)
}

Copy link
Contributor

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?

Copy link
Contributor Author

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 😂)

Copy link
Member

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.

Copy link
Contributor Author

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

@harshit-gangal
Copy link
Member

I have looked through the doc. Looks good to me

doc/viper/viper.md Show resolved Hide resolved
go/viperutil/debug/debug.go Show resolved Hide resolved

// 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

Copy link
Contributor Author

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Andrew Mason and others added 15 commits May 23, 2023 16:08
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>
Signed-off-by: Andrew Mason <andrew@planetscale.com>
@ajm188 ajm188 force-pushed the andrew/viper-rfc branch from 2324853 to dee064f Compare May 23, 2023 20:09
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.")
Copy link
Contributor

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().

Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: General Changes throughout the code base Type: Feature Type: RFC Request For Comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants