Content resources may be used by one or more bundle deployments, which now each add their own finalizer on a content resource to indicate their reliance on it, and delete that finalizer when that reliance no longer applies.
This eliminates the need for batch cleanup of content resources.
Manual tests suggest that this approach is backwards compatible, having done the following:
Deployed Fleet built from main
Created a test GitRepo, which led to creation of a bundle deployment with its Content resource (without any finalizers)
Ran helm upgrade --install updating Fleet to a version containing this refactor
Saw the previously created Content resource being updated with a new finalizer
Deleted the above test GitRepo, which deleted the Content resource
Refers to #2464
Open points:
should the edge case of a GitRepo transitioning from etcd- to OCI-stored contents be automatically tested here, or could this be taken into account through QA efforts?
is this backwards compatible? Pending Fleet upgrade tests on my end, hence leaving this in draft state in the meantime.
Content resources may be used by one or more bundle deployments, which now each add their own finalizer on a content resource to indicate their reliance on it, and delete that finalizer when that reliance no longer applies.
This eliminates the need for batch cleanup of content resources.
Manual tests suggest that this approach is backwards compatible, having done the following:
mainGitRepo, which led to creation of a bundle deployment with itsContentresource (without any finalizers)helm upgrade --installupdating Fleet to a version containing this refactorContentresource being updated with a new finalizerGitRepo, which deleted theContentresourceRefers to #2464
Open points:
GitRepotransitioning from etcd- to OCI-stored contents be automatically tested here, or could this be taken into account through QA efforts?