-
Notifications
You must be signed in to change notification settings - Fork 411
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
controller-gen feature request: support objectSelector in webhook config generation #553
Comments
This is solvable with a strategic merge patch in kustomize:
But a marker parameter sure would be nice. :) |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Still unimplemented. Patches via kustomize are not always viable (when e.g. the source of truth is in *.go files). To me it looks like it would boil down to extending the config (and parsing rules): controller-tools/pkg/webhook/parser.go Lines 61 to 136 in 76b24b2
objectSelector makes it a bit more nuanced to "get right" than other fields.
I'd be willing to contribute this if we have any idea how we'd like to API to look like. A quick draft that I can come up with:
but I'm not sure if that's the way forward. cc: @sbueringer /reopen |
@pmalek: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Any updates on this? |
@pmalek I think I would add a field named "ObjectSelector" to the Config struct the type would be a copy of Do you see parts of that struct where it would be necessary to diverge from that? |
@sbueringer That sounds good 👍 I'm not sure what will be the resulting interface but the approach is sound to me. I can work on that but I won't have time for this in the upcoming 2 weeks (or so). If anyone beats me to it feel free to jump on this. |
Sounds good! |
Currently (v0.5.0) the
+kubebuilder:webhook
marker does not support setting anobjectSelector
on a webhook.objectSelector
is especially handy when mutating or validating core types. For example, I want to be able to set an environment variable on a subset of pods in a particular namespace, but not my controller manager pod, which runs in the same namespace and runs the webhook server.I realize that the docs recommend running the webhook server in a separate namespace and scoping the validation to the target namespace to avoid deadlock, but that's not feasible for various reasons. Setting a label on the pods I want to mutate works perfectly fine but there's no way to do it (that I know of) without breaking my workflow, which involves generating the MutatingWebhookConfiguration with markers and patching it with kustomize in one shot. (I'm using a lightly modified version of what
kubebuilder init
provides.) I could patch the objectSelector field if it were there in the generated config.I propose something as simple as an optional
objectSelectorLabel=string
that generates the following:Where
foo
is the user-provided string andpatchMe
is some default that the user can patch.I'm happy to put something together if there's an appetite for it.
The text was updated successfully, but these errors were encountered: