PVC deselect/delete for VR #2086
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit 1203605 updated DRPC orchestration to ensure that VRG is Secondary on the cluster before workload is cleaned up, which includes PVCs. As a result in VRG orchestration, additional stricter latches are added to determine when to process PVC deletion or deselection as a separate operation from workload deletion due to DR actions. IOW, PVCs that are deleted/deseected when VRG is primary and not in preparing or executing final sync states, are user deleted PVCs that do not need further protection. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
Some minor corrections to handling PVC deselect/delete for VR use cases - Remove VolumeUnprotectionEnabledForAsyncVolRep as it is not required any further, instead if DRPC sets the ramen config option VolumeUnprotectionEnabled VRG can act on PVC deselect/delete as DRPC orchestration would be stricter - Cleanup of protected PVCs status is not required at the end of PVC deselection, as the called PVC deselection functions for VR/VS are expected to cleanup protected PVCs Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
If VRG update fails due to conflict, we need to get the resource again before retrying. This was not happening causing intermitent failures in the related test. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
Currently a missing VR, or a requeue return from reconcileMissingVR, in the flow dealing with PVC deselection or deletion, sets requeue as true for the VRG. This causes the PVC to not be removed from the protected PVC status output in pvcUnprotectVolRep. If reconcileMissingVR reports a missing VR, then processing the PVC further should stop, and a requeue for the VRG should only be setup when it returns requeue as true. This is corrected with this commit. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
ba2d438 to
837f69c
Compare
|
e2e testing report:
Tested with Subscription based applications and RBD backend, by adding another deployment with the same PVC labels to the namespace, resulting in additional PVCs protected (and hence can be deselected/deleted and used to test the flows in this PR). Testing required updating ramen config at the hub to set |
4 tasks
BenamarMk
approved these changes
Jun 18, 2025
|
Merged as part of #2095 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Commit ShyamsundarR@1203605 updated DRPC orchestration to ensure that VRG is Secondary on the cluster before workload is cleaned up, which includes
PVCs.
As a result in VRG orchestration, additional stricter latches are added to determine when to process PVC deletion or deselection as a separate operation from workload deletion due to DR actions.
IOW, PVCs that are deleted/deselected when VRG is primary and not in preparing or executing final sync states, are user deleted PVCs that do not need further protection.
Some minor corrections to handling PVC deselect/delete for VR use cases are also included:
Remove VolumeUnprotectionEnabledForAsyncVolRep as it is not required any further, instead if DRPC sets the ramen config option VolumeUnprotectionEnabled VRG can act on PVC deselect/delete as DRPC orchestration would be stricter
Cleanup of protected PVCs status is not required at the end of PVC deselection, as the called PVC deselection functions for VR/VS are expected to cleanup protected PVCs
Fix envtest failure in multi-namespace support, [BeforeAll]