Restructure flag usage across vitess
ajm188 opened this issue · 1 comments
Problem Statement
Vitess's flag usage has evolved over the life of the project into a sort of organic sprawl.
Flags are defined on the global flag.FlagSet in the packages that use them, meaning that a binary that imports that package (or imports a package which imports a package which imports ....) implicitly gets that flag defined and that flag will appear in the binary's help text, whether the flag makes sense or not. This impacts the discoverability and ease-of-use of the various binaries.
In addition, this imposes maintenance burdens. When a new flag is introduced, care must be taken to avoid name collisions (even if you are adding a flag which is only used by vttablet, it may end up importing a flag that's really only used by vtgate but happens to share the same name), and it is difficult to extract small pockets of functionality, because you end up importing all the flags anyway.
These two issues are somewhat entangled with each other, and are some of the primary motivations, in addition to overall binary size, raised in a more general binary structure RFC in vitessio/vitess#7471.
This VEP aims to cover just the flag restructuring, in a way that can be folded into the broader refactor with few if any (ideally, none at all) changes. However, I believe this work is important enough on its own, such that we should do it regardless of that work stream, but also we should design this work in a way that is compatible with that work stream, if that distinction makes sense.
Goals
The design should aim to achieve the following:
- Importing vitess packages (e.g.
package topo) should not mutate the global flagset implicitly. Binaries should need to be explicit about exactly which packages' flags should be usable by that binary, including at the cost of increased verbosity in the code. - The design should enable a modular approach to vitess commands and subcommands, as laid out in vitessio/vitess#7471.
- The design should not prohibit a move to config-file based approaches, such as viper.
Non-Goals
- The design should not prescribe a particular approach to vitess commands and subcommands, as that is a slightly higher-level, although related, concern.
- The design should not require a move to a library such as viper.