Replies: 3 comments
-
Hey @xrstf the purpose of the webhook is to check if a change to the DO LB parameters would result in a valid configuration. If not, the request will be rejected. This is to protect against scenarios where a user (inadvertently) produce a flawed LB configuration, which then breaks the LB (and all further reconciliation attempts, including adjustments to the target droplet set). Worth highlighting that the webhook does not really create or update LBs: it sets a validation flag that causes the LB backend to check the configuration in a what-if manner without actually mutating any LB resources. You are free to remove / omit the webhook, which will basically give you the old behavior again (meaning that you need to watch out for events to detect any LB misconfigurations). Apologies, I think we missed to accompany the change with enough documentation which we will follow up on (/cc @prichrd). |
Beta Was this translation helpful? Give feedback.
-
#689 was merged which amends the documentation and separates the manifests more clearly. |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for the clarification :-) |
Beta Was this translation helpful? Give feedback.
-
We noticed today that the CCM v0.1.47 now ships with an included ValidatingWebhook. We looked through the code and from first glance it seems that the webhook is doing synchronous requests to the Digitalocean API and the webhook is now part of the reconciling behaviour (it does
.Create()
and.Update()
calls).We're wondering if the webhook is now required. Also if our understanding of the webhook's behaviour is accurate and if so, why reconciling is now doing not in a controller loop, but in a blocking manner via the webhook.
Beta Was this translation helpful? Give feedback.
All reactions