-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
🐛 Start web hooks first #1690
🐛 Start web hooks first #1690
Conversation
NOTE: starting the webhooks in CAPI (where we have about 15 to 20 webhooks) takes about 100ms; as a side effect this start cache faster in case they requires conversion |
This seems cleaner than the other PR, +1 on merging |
I like the approach. Any chance we could test this? |
@alvaroaleman When I first moved the code to run webhooks first there wasn't a nice way to do it from the outside. |
3bee7ab
to
cc6d878
Compare
I will take a look about tests tomorrow morning, at least this is a chance to learn this part as well |
Maybe just set up a manager with a webhook and a runnable that does a http request to the webhook in its |
While investigating unit tests, we are testing this with CAPI and we just found some problems in https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_cluster-a[…]ager/capi-controller-manager-5d857f645f-wpv8v/manager.log It seems we still have deadlock with the health probes. If the health probes are not started our conversion webhook won’t be accessible as the Pod doesn’t get ready. |
I have a test ensuring webhook start before cache. |
Let's close it once/if the other one merges, this fix can probably be rebased on top of release-0.10 |
cc6d878
to
b267bb5
Compare
@fabriziopandini: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/retest |
b267bb5
to
b6a5752
Compare
@vincepri rebased on to of the release 0.10 branch |
@fabriziopandini Can you please include the change in: fabriziopandini#1 ? The problem is that otherwise we'll have the same deadlock just with the healthprobes. I would then take this version and rebase my 2 test PRs in CAPI to run all our tests with and without leader election |
Co-authored-by: Stefan Büringer <[email protected]>
Done! |
Thx! Tests are running here:
P.S. I might need a few tries, just refactored those branches back to use CR release-0.10 instead of main. UPDATE: tests are all green |
@fabriziopandini WDYT, ready for review/squash/un-wip? :) |
Removed WIP, given #1690 (comment) @vincepri @alvaroaleman PTAL |
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
/milestone v0.10
@vincepri: The provided milestone is not valid for this repository. Milestones in this repository: [ Use 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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini, 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 PR test a simpler and possible cleaner solution to #1685.
We should test how this impact start time