I'd like to use the manager's client to reference a configmap when validating my custom resource. But I can't see a way to pass the manager's client through to the webhook code (the Defaulter) when using the NewWebhookManagedBy form:
func (r *FirstMate) SetupWebhookWithManager(mgr ctrl.Manager) error {
return ctrl.NewWebhookManagedBy(mgr).
For(r).
Complete()
}
A related question put me on to the .Register form which I think would let me pass down the manager's client to the code that would be triggered by the webhook.
I might end up loading the configmap as an env var (I've read you can do this though can't find an example). But I'm wondering is it intended that the SetupWebhookWithManager doesn't let you use a client inside the webhook code? Or perhaps I'm missing something?
If that's what you really want, why not change your FirstMate and add a client Client attribute to its struct, so that then you can...
func (r *FirstMate) SetupWebhookWithManager(mgr ctrl.Manager) error {
聽聽聽聽c := ctrl.NewWebhookManagedBy(mgr).
聽聽聽聽聽聽聽聽For(r).
聽聽聽聽聽聽聽聽Build()
c.client = mgr.GetClient()
r.controller = c
return nil
}
Wouldn't the client then be an attribute on the custom resource (FirstMate in this example case and so be treated as part of the CRD and included in the generated CR definition?
~According to the snippet of code you pasted, FirstMate is the name of your controller/reconciler.~ oh wait, you're right. Let me read the linked code and I'll come back to you.
Maybe something like...
```go
var (
firstmatelog = logf.Log.WithName("firstmate-resource")
client Client
)
func (r *FirstMate) SetupWebhookWithManager(mgr ctrl.Manager) error {
client = mgr.getClient()
return ctrl.NewWebhookManagedBy(mgr).
For(r).
Build()
}
var _ webhook.Defaulter = &FirstMate{}
// Default implements webhook.Defaulter so a webhook will be registered for the type
func (r *FirstMate) Default() {
firstmatelog.Info("default", "name", r.Name)
// TODO use client to read other resources
client.Get(...)
// TODO(user): fill in your defaulting logic.
}
Do have in mind the client will need access to the scheme(s) of the type(s) you'll be interacting with.
Yeah that approach works - https://github.com/SeldonIO/seldon-core/pull/1118/commits/0202671d8dec00a84b801151043576ba6a4bfdce#diff-e35f762db386aef706a8b20d09081fb9R99
If you need to use a client, I'd reccomend using the lower-level webhook machinery in pkg/admission/webhook.
we really need an FAQ item on this
https://github.com/kubernetes-sigs/controller-runtime/issues/780 - I get an error following the example.
solved this. example in here https://github.com/kubernetes-sigs/controller-runtime/issues/780#issuecomment-578515689
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
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.
Most helpful comment
we really need an FAQ item on this