Discuss flag / config pkg usage

[wiardvanrij]

Problem description

The current package for flags that is used, is Kingpin. Which is still feature stable, but is in contribution mode.
When we require new features or hit an issue, this would get committed / merged but there are no active releases. This means making a replace in our go.mod to the latest commit hash.
For example #4034 requires an update of the kingpin pkg.

There are also a few issues regarding using flags / configuration for other uses-cases. For example generating structs for flags. Improving our documentation (automatically) based on flags.

I figured to make a single discussion on this subject to gather requirements, input, feedback and move this towards actionable items that might be related to each other. I.e. generate structs might correlate with having a solid flag pkg. I'm not saying we must replace kingpin but it could be an option.

Related issues / discussions / PR's

#3924
prometheus/prometheus#2455
prometheus/prometheus#7026
#2267
#4062
#3888
#3622

Maybe relevant
#2248

Suggestions - what we would like to see

• Generate Structs for Flags or Output machine-reable description for flags (Generate Structs for Flags or Output machine-reable description for flags #3924)

Self-describing-binaries is kind of how I see this. I like this idea a lot. I personally think just a json blob that describes the subcommands and flags of those is a really fantastic start. Little can do a lot here I believe.

Originally posted by @brancz in #3924 (comment)

Something like https://github.com/alecthomas/kong might help you.

Originally posted by @roidelapluie in #3924 (comment)

I just had chat with @smintz, co-creator of similar project https://github.com/protoconf/protoconf, I think we plan to join forces into going for proto based configuration (alongside flags ofc)

Originally posted by @bwplotka in #3924 (comment)

snip

1. It’s not clear what fields from the Go struct are actually set from flags, which are manually set. Especially for nested configuration structs. It’s worth noting that overall, as mentioned by Peter Bourgon, mixing user intent with derived config is a bad design smell. Such a mistake is quite hard to detect with flag definition like above.
2. It’s easy to miss that some configuration variable is not used anymore, but some flag is still defined for it. This is because Go will not detect it being used, as it’s passed in, for example, DurationVar(&cfg.var). In fact, during the move of Prometheus flags to my library, I found that one config field was exactly like this.
3. We just defined a field in configuration struct, why we need to create additional 2 complex lines for each of it?
4. What if we would like to parse our configuration from JSON or YAML as well? It would require huge refactoring.
5. What about complex flags like Thanos’s path or content? Registering of those is quite tedious.

Originally posted by @bwplotka in prometheus/prometheus#7026 (comment)

As discussed in community meeting;

• Keep config/flag information on components pages
• Automate from code/structs into md
• Gather info from various parts/configs/components into that single caching page. Just like storage for example

Originally posted by @wiardvanrij in #3888 (comment)

Actions

• Make sure we have our suggestions / use-cases complete
• Define requirements
• -> Move to actionable issues

LMK if this would work.

@thanos-io/thanos-maintainers

[bwplotka]

Thanks for starting this discussion. I would just add this https://github.com/openproto/protoconfig to our discussion. It would help us enormously.

It's also worth to mention that ideally the current way of configuring does not change - to avoid breaking changes.

[sevagh]

I hate to be contrarian (and have no authoritative voice here - my ideas might be ridiculous)

Just some vague thoughts - I think using whatever super popular 10 million GitHub star cli package of the day is a losing proposition (dealing with the library's own opinionatedness, momentum, and most likely inevitable downward swing in momentum and community interest).

Prometheus for example built its own promu tool to manage Prometheus releases. Why not have aim for something fresh and new for Thanos, based on the stdlib (and some well-vetted third party packages) to customize the behavior? Looks like protoconfig above is a step in that direction.

Maybe Thanos could be the exemplar child for the protoconfig library?

tl;dr I trust Thanos maintainers to write important libraries, much more than the most-popular-library-of-the-day (which comes with maintainership cost if your needs don't align perfectly). Thanos is a big enough ecosystem of interacting Go binaries and related documentation that it could be a nice place to write a custom cli framework just for Thanos which works great.