-
Notifications
You must be signed in to change notification settings - Fork 1.2k
⚠ Handle finalizers in the fake client #1399
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
⚠ Handle finalizers in the fake client #1399
Conversation
Welcome @tjamet! |
Hi @tjamet. 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/test-infra repository. |
The fake client differs significantly from the real implementation. With the real client implementation, upon the deletion of a resource, when finalizers are set the DeletionTimestamp is filled with a non-null value. This triggers a number of reconciling loops for all controllers that then can take the opportunity to inspect the resource being deleted, perform the required cleaning actions and then update the resource by removing their finalizers as the cleaning job have been done. In the current implementation, the Delete function implements a straight delete and hence triggers a false positive or negative test when trying to run tests at the client level, without interacting with the objects. For example: ``` client.CreateObject() controller.Reconcile() Expect(Something).To(BeDone()) client.DeleteObject() controller.Reconcile() Expect(SomethingElse).To(BeDone()) ``` In the real life, SomethingElse would actually be done as the controller would still have access to the resource. In the current fake implementation, this is not the case as the controller does not have access to the resource any longer.
755c845
to
4f23760
Compare
I think the PR is ready on its own. I didn't implement yet the feature in |
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.
/ok-to-test
This is a breaking change and needs to be marked as such
/retest |
Sure! shall I use ⚠ then? |
Yes, please.
Can you implement that as well, please? Not having it there will surprise users. |
Sure! I will push it soon |
b53c144
to
286a287
Compare
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.
/label tide/merge-method-squash
/lgtm
/approve
thank you!
@alvaroaleman: The label(s) 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: alvaroaleman, tjamet 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 |
/hold |
/hold cancel |
Update tests for controller-runtime changes from 0.8.2 to 0.9.2(+). Most of these changes react to kubernetes-sigs/controller-runtime#1399, which made the fake client's Delete behave more like the real thing: - If the object has finalizers, set `DeletionTimestamp` but don't actually delete. - If there are no finalizers, actually delete. - Updates that remove the last finalizer from an object with a `DeletionTimestamp` actually delete the object. Then there's kubernetes-sigs/controller-runtime#1390 which deduplicates objects in the reconcile queue for Update actions.
* Handle finalizers in the fake client The fake client differs significantly from the real implementation. With the real client implementation, upon the deletion of a resource, when finalizers are set the DeletionTimestamp is filled with a non-null value. This triggers a number of reconciling loops for all controllers that then can take the opportunity to inspect the resource being deleted, perform the required cleaning actions and then update the resource by removing their finalizers as the cleaning job have been done. In the current implementation, the Delete function implements a straight delete and hence triggers a false positive or negative test when trying to run tests at the client level, without interacting with the objects. For example: ``` client.CreateObject() controller.Reconcile() Expect(Something).To(BeDone()) client.DeleteObject() controller.Reconcile() Expect(SomethingElse).To(BeDone()) ``` In the real life, SomethingElse would actually be done as the controller would still have access to the resource. In the current fake implementation, this is not the case as the controller does not have access to the resource any longer. * Handle finalizers when deleting collections
Fake client now respects finalizers, if any are present delete functionality will simulate real cluster resource delete More info: kubernetes-sigs/controller-runtime#1399 Signed-off-by: ehila <[email protected]>
Fake client now respects finalizers, if any are present delete functionality will simulate real cluster resource delete More info: kubernetes-sigs/controller-runtime#1399 Signed-off-by: ehila <[email protected]>
Signed-off-by: ehila <[email protected]> fix: unit test for cleanup stale state Fake client now respects finalizers, if any are present delete functionality will simulate real cluster resource delete More info: kubernetes-sigs/controller-runtime#1399 Signed-off-by: ehila <[email protected]> fix: updated unit tests mock object with max call Signed-off-by: ehila <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
Broke after we bumped and got kubernetes-sigs/controller-runtime#1399 Signed-off-by: Alex Kalenyuk <[email protected]>
The fake client differs significantly from the real implementation.
With the real client implementation, upon the deletion of a resource,
when finalizers are set the DeletionTimestamp is filled with a non-null
value.
This triggers a number of reconciling loops for all controllers that then
can take the opportunity to inspect the resource being deleted, perform
the required cleaning actions and then update the resource by removing
their finalizers as the cleaning job have been done.
In the current implementation, the Delete function implements a straight
delete and hence triggers a false positive or negative test when trying
to run tests at the client level, without interacting with the objects.
For example:
In the real life, SomethingElse would actually be done as the controller
would still have access to the resource. In the current fake implementation,
this is not the case as the controller does not have access to the
resource any longer.