✨ Handle Kubernetes events for waiting CoreProvider in preflight check #703
Conversation
|
Hi @dmvolod. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
✅ Deploy Preview for kubernetes-sigs-cluster-api-operator ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
cc4dcda to
37bc644
Compare
|
/ok-to-test |
37bc644 to
eac17b0
Compare
eac17b0 to
92644ba
Compare
326a0b8 to
a1b9dc6
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: furkatgofurov7 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 |
|
LGTM label has been added. Git tree hash: 5484b1c9e0ccac846e99df5d889b370de30531d4
|
What this PR does / why we need it:
This PR allows you to avoid from polling in reconcile loop every 30 seconds, and move to catching events from the CoreProvider object when Ready condition become True. We should avoid re-querying at intervals where possible.
Also, configSecret request is optimized if option is enabled. Since a cluster can have a large number of secret objects, it is a very expensive procedure to go through all the providers each time secrets are catches without an index. The number of provider objects in the cluster is small enough that the index on the name/namespace fields will not be very large.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #