-
Notifications
You must be signed in to change notification settings - Fork 8
Minor corner-case improvements in SubNamespace reconciler #169
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
Conversation
54787e4 to
820d07e
Compare
|
@ymmt2005 I would really love your review of this PR if you have time! 🙏 |
b7767e7 to
124eff1
Compare
|
I believe the failing check is a flake. Is there a way for me to retrigger the job? |
|
@erikgb |
|
Thanks @zoetrope! I managed to re-run the failing job now. |
| Namespace: parent, | ||
| Name: o.GetName(), | ||
| }}) | ||
| return |
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.
I confirmed that removing this return statement resolved the issue👍
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, then I will update the PR description to close the issue when this PR is merged. How do you explain the non-failing e2e-test? It is testing exactly this.
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.
In #168, the conflicting Namespace was created as a SubNamespace, so the Namespace has a parent label.
In contrast, in the test, the Namespace is created directly and therefore doesn’t have a parent label.
As a result, it doesn’t meet the condition at the following line, and the Reconcile process for SubNamespaces is triggered.
| if parent != "" { |
| controllerutil.RemoveFinalizer(sn, constants.Finalizer) | ||
| return r.Patch(ctx, sn, client.MergeFrom(orig)) | ||
|
|
||
| // We'll use a JSON Merge Patch here to avoid removal of finalizers added by other controllers |
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.
Based on my testing, it appears that even with the previous code, finalizers added by other controllers would not have been removed.
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.
Yes, that's probably true. But as the finalizer is added by our admission webhook, I think it makes sense to remove it as precisely as possible. And a JSON patch is the most exact we can use AFAIK. So I don't think this harms. Do you want me to revert this change?
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.
No problem. This implementation works for me.
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.
@erikgb
I think this can be merged as is. If you feel that additional tests are needed, please feel free to add them.
Thanks @zoetrope. I would love to write a new end-to-end test to verify that this PR fixes the linked issue, as it cannot be tested with envTest. Thanks for explaining how this case differs from the e2e-test we already have. |
124eff1 to
91b0c8b
Compare
|
@zoetrope, sorry for the very long delay, but I have now added an e2e-test to verify that this PR fixes the issue. I created a draft PR to verify that the test is effective: #196. I would have preferred to write an integration test (envTest), but envTest doesn't support namespace deletion, as documented in the kubebuilder book. Please review when you have some time! |
zoetrope
left a comment
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!!
This PR will hopefully address #168, but it's a bit hard to know for sure, since I was unable to reproduce the issue in tests, even if the issue is 100% reproducible in one of our clusters. 🤔 I suggest keeping #168 open until the issue isn't reproducible in a real cluster.
This PR should be reviewed carefully, but some of the main things I have tried to address are:
SubNamespaceon finalization. I'm personally not a great fan of thegotoconstruct, and it's even more confusing when the goto is namedDELETE, which is misleading IMO.deletionTimestampset).Fixes #168
Closes #196