-
Notifications
You must be signed in to change notification settings - Fork 532
fix: ignore non-targeted clusters during deletion #1499
fix: ignore non-targeted clusters during deletion #1499
Conversation
Welcome @jonathanbeber! |
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.
Thanks @jonathanbeber for taking point on this. The changes look good to me but I'd like to see some tests added to the PR. Most of the tests are defined in test/e2e so you might want to add tests pertaining to this new behaviour there.
@jimmidyson @hectorj2f would you mind approving the workflow runs on this PR, please? |
Approved and ran |
45c7567
to
74e0510
Compare
can someone please approve the CI once again? |
CI ran and it seems ok, could some please review/approve? |
Any review is appreciated |
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.
just a nit, otherwise lgtm
thank you @makkes! |
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.
Nice work! 👏🏻
/lgtm |
/assign @irfanurrehman |
@jonathanbeber please check the CI failures. |
During the deletion of resources, the controller errors if any cluster is marked as non-ready. That leads to objects being stuck during deletion while these clusters are present, even if the resource is not deployed in such clusters. This commit makes the reconciliation for deletion to compute the placement of the federated resources and ignore other clusters. This way, the deletion will fail just if the non-ready clusters are the clusters where the object is federated.
The e2e tests do not consider any unhealthy cluster. This commit adds a test case where the cluster federates itself twice and makes one the virtual federation not-ready by changing the API endpoint to an invalid address. The ready cluster is labelled and a complete CRUD test guarantees that the not-ready cluster does not impact operations if the the cluster is not targeted.
That's really strange, the last commit just changes the year in the initial comment of a file. Checking further |
9dc3772
to
d19b80c
Compare
@irfanurrehman could you please approve the CI run again? |
It seems good to merge now @irfanurrehman |
Thanks for doing this @jonathanbeber /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: irfanurrehman, jonathanbeber, makkes 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 |
What this PR does / why we need it:
During the deletion of resources, the controller errors if any cluster
is marked as non-ready. That leads to objects being stuck during
deletion while these clusters are present, even if the resource is not
deployed in such clusters.
This commit makes the reconciliation for deletion to compute the
placement of the federated resources and ignore other clusters. This
way, the deletion will fail just if the non-ready clusters are the
clusters where the object is federated.
Which issue(s) this PR fixes
Fixes #1254
Special notes for your reviewer: