Garbage collection for Update objects #733
Assignees
Labels
good-first-issue
Start here if you'd like to start contributing to Pulumi
impact/usability
Something that impacts users' ability to use the product easily and intuitively
kind/enhancement
Improvements or new features
resolution/fixed
This issue was fixed
Comments
|
Added to epic #586 |
5 tasks
EronWright
added
the
good-first-issue
blampe
added
kind/enhancement
Open
EronWright
added a commit
that referenced
this issue
Feb 11, 2025
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md)
for Pulumi's contribution guidelines.
Help us merge your changes more quickly by adding more details such
as labels, milestones, and reviewers.-->
### Proposed changes
<!--Give us a brief description of what you've done and what it solves.
-->
Implements a retention policy for completed Update objects, based on a
simple TTL with the default value of 24h. Update objects that are in a
completed state and are older than the TTL are summarily deleted.
#### New API: `Update.spec.ttlAfterCompleted`
A new field to enable garbage collection of this update, once completed.
Optional; no default value.
#### Update Controller
Updated to implement the cleanup logic. When a TTL is set on a completed
update, the controller looks to the last transition time of the
Completed status condition. If there's time remaining, the controller
requeues the object for later, otherwise it deletes the update object.
#### Stack Controller
Updated to assign a 24-hour TTL on the update objects that it creates. A
future enhancement would be to provide an `updateTemplate` field to
allow for further control. A user may edit an existing Update to change
the TTL.
#### Update Controller Tests
A new unit test was added to exercise the retention logic.
### Related issues (optional)
<!--Refer to related PRs or issues: #1234, or 'Fixes #1234' or 'Closes
#1234'.
Or link to full URLs to issues or pull requests in other GitHub
repositories. -->
Closes #733
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Updateobjects accumulate indefinitely in the system, and the operator should cleanup the old completed updates, e.g. after a week or so.Should the Update controller handle the cleanup uniformly? Or should the Stack controller handle the cleanup for the updates that it owns? I would lean towards the former, by introducing a
Update.spec.ttlSecondsAfterFinishedfield that theStackcontroller may set and is implemented by the Update controller.Verify that the output secret for a given update is cleaned up.
See https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/
The text was updated successfully, but these errors were encountered: