-
Notifications
You must be signed in to change notification settings - Fork 1.2k
✨ Structured args in Testing #1541
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
✨ Structured args in Testing #1541
Conversation
a0649c7
to
e3b6d3c
Compare
This should make it a bit easier to manage argument overrides than the set of templates we have now, especially while we wait for componentconfig to be everywhere. Arguments can be defaulted, and those defaults can be overriden or appended to, and then finally render to a slice of strings to be passed as arguments and such. This should make it easier to configure the API server without needing to splat out the existing default arguments, maybe splice some stuff out, etc. For example: ```go apiServer.Configure(). Disable("insecure-port"). Append("vmodule", "httplog.go=10"). Set("v", "5") ```
This converts the internal testing package to use structured arguments, introducing a new helper to preserve compat when specifying legacy args.
e3b6d3c
to
ddfdfdf
Compare
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.
/lgtm
/retitle ✨ Structured args in Testing
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: DirectXMan12, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This adds structured arguments to the testing package, deprecating the old style where we do templating in favor of a fluent API with defaults that can be overridden.
This should make it easier for consumers to override individual arguments while not breaking the necessary flags that are required for the API server to function, and should make it easier for us to deal with upcoming changes in the k8s API server that requiring setting flags in some conditions, but not in others that are unrelated to the value of the flag (e.g. certain flags must be passed for older versions, but must NOT be passed for newer versions).
The new API looks roughly like:
There's also a helper to merge the new arguments with the older style ones. To preserve existing behavior, if the end user explicitly passes a template, we'll consider those to be the "defaults", otherwise we'll use our normal new default logic.
Depends on #1540
Part of #1486