-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
✨ add webhook readiness and health check #4989
✨ add webhook readiness and health check #4989
Conversation
/cc @vincepri |
/lgtm great to see that we can do this now cc @devigned |
Oh, cool! +1 |
Signed-off-by: Stefan Büringer buringerst@vmware.com
9a4efa2
to
bc720b4
Compare
Had to rebase |
/lgtm |
Great! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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 |
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up. The current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources. Follows: kubernetes-sigs/cluster-api#4989
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up. The current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources. Follows: kubernetes-sigs/cluster-api#4989
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up. The current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources. Follows: kubernetes-sigs/cluster-api#4989
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up. The current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources. Follows: kubernetes-sigs/cluster-api#4989
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up. The current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources. Follows: kubernetes-sigs/cluster-api#4989
Signed-off-by: Stefan Büringer buringerst@vmware.com
What this PR does / why we need it:
Currently the readiness of our controller deployments does not include the webhook server. I.e., the deployment is already ready even when the webhooks are not up.
So when we implement a wait for deployments ready in #4934 the current PR will help that the wait for readiness will also include the webhook server. This is crucial because otherwise there's a chance that clusterctl immediately fails when we try to deploy resources.
Note: This controller-runtime health check is only available since v0.9.3 (kubernetes-sigs/controller-runtime#1598)
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Improves the accuracy of the wait we'll implement in #4934 for #4474
Follow-up: