-
Notifications
You must be signed in to change notification settings - Fork 19
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
(feat): automatically delete temporary resources #248
Conversation
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## main #248 +/- ##
==========================================
+ Coverage 71.75% 72.18% +0.42%
==========================================
Files 13 13
Lines 2160 2193 +33
==========================================
+ Hits 1550 1583 +33
Misses 477 477
Partials 133 133
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
So far so good.
Just a word of caution, these types did not have owner references on them before and because the owner reference has Controller: true on them it will requeue the parent object any time this object changes. If that behavior doesn't mess with the actual parent object we are good but I believe it will run them through the loop and cause a cascading deletion problem being that the parent object is requeued.
This is used for garbage collection of the controlled object and for reconciling the owner object on changes to controlled (with a Watch + EnqueueRequestForOwner).
Co-authored-by: Troy Connor <troy0820@users.noreply.github.com> Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
05f0df6
to
9e05026
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.
Just a couple of changes, and the testing effort may need to be done in an env test or some integration that can show that the resources are cleaned up and the default value is set.
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
…what this will break Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
…one of those Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
… sure this is the problem Signed-off-by: schristoff <28318173+schristoff@users.noreply.github.com>
Closing due to breaking this apart |
This is an attempt to solve #54 - I added OwnerReferences to some smaller resources to make sure they get cleaned up.
Unsure if we should add the
TTLSecondsAfterFinished
to that resource as it has this note: