Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of your changes
The purpose of the
bucket-in-use
finalizer was to ensure that (1) a Bucket CR could not be removed whilst it still has corresponding S3 buckets existing on Ceph backends and (2) in a system where Bucket CRs are managed by a separate controller or component, a separate actor could not simply delete a Bucket CR (by accident or otherwise).However, scenario (1) is covered by the Crossplane
managed
finalizer.Scenario (2) is not covered by the
managed
finalizer, but upon reflection it should not be the responsibility of Provider Ceph to add an "in-use" finalizer. It should instead be the responsibility of the controller/component that creates the Bucket CR.Provider Ceph managing it's own "in-use" finalizer causes an issue whereby failure to remove the finalizer after successful deletion is not requeued by Crossplane as it assumes that the only finalizer it should care about is its own
managed
finalizer.This can lead to a scenario where deleting a Bucket CR can result in the successful removal of all buckets from backends, however the kube API update to remove the finalizer fails and the CR is left hanging forever.
I have:
make reviewable
to ensure this PR is ready for review.make ceph-chainsaw
to validate these changes against Ceph. This step is not always necessary. However, for changes related to S3 calls it is sensible to validate against an actual Ceph cluster. Localstack is used in our CI Chainsaw suite for convenience and there can be disparity in S3 behaviours betwee it and Ceph. Seedocs/TESTING.md
for information on how to run tests against a Ceph cluster.backport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
CI + e2e