Support DeleteSnapshot Retries in SnapshotWriter #8456
Merged
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
Enhance the DeleteSnapshot method of the SnapshotWriter to consume the same retryOptions that the WriteSnapshot operation uses
Context
Why is this necessary?
When deleting resources in bulk, we may delete a resource and while gloo is processing that deleting, we delete another resource that references it. This will result in Gloo rejecting the deletion of the second resource. In a perfect world, Gloo could handle these bulk updates. However, for now, we mirror how we handle writing resources in bulk in tests, we just retry the whole operation. This retry gives time for Gloo to process the changes, and eventually accept the proposed deletion.
How is this tested?
I wrote a kube2e test which configures a resource that does not exist. In the past, this would have thrown an error. We now swallow "does not exist" errors, to ensure we can retry operations. The test demonstrates that we successfully swallow these errors and continue deleting the snapshot.
This does NOT test that we retry correctly. However, this logic is identical to the writeSnapshot logic, so I decided it was ok to not have full test coverage. Also, if we see that flakes are still existing, then it will be a signal that there is a gap in the functionality.
Checklist:
make -B install-go-tools generated-code
to ensure there will be no code diff