Implement PVC deselect/delete for PVCs protected by VGR #2095
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
|
Built on pr #2086 |
ELENAGER
reviewed
Jun 16, 2025
|
|
||
| return nil | ||
| } | ||
|
|
There was a problem hiding this comment.
For this and the next code snippet maybe we could consider using a shared function, something like this:
func shouldSkipPVCAction(spec ramendrv1alpha1.VolRepGroupSpec, log logr.Logger, action string) bool {
if spec.ReplicationState != ramendrv1alpha1.Primary ||
spec.PrepareForFinalSync ||
spec.RunFinalSync {
log.Info(
fmt.Sprintf("PVC %s skipped", action),
"replicationstate", spec.ReplicationState,
"finalsync", spec.PrepareForFinalSync || spec.RunFinalSync,
)
return true
}
return false
}
ELENAGER
reviewed
Jun 16, 2025
ELENAGER
reviewed
Jun 16, 2025
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>
Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
Implements pvcUnprotectVolGroupRep which removes protection for a PVC when VRG is Primary and is protected by VGR in a CG. The unprotection works as follows: - Sets the CG label value to an empty string, ensuring the PVC is deselected from the CG that it belongs to - Ensures the PVC is no longer reported as part of the VGR status as protected - Deletes the VGR if it was protecting only this PVC - Removes PV/PVC protection metadata As the order ensures that the last action for the PVC is to remove its CG label, the entire workflow is idempotent across multiple reconcile loops. Further, all errors/progress is reported into the PVC DataReady condition. An additional change is made to pvcsUnprotectVolGroupRep to set VRG for requeue only if reconcileMissingVGR returns a requeue. If it reports a missing VGR and no requeue, then further processing of the VGR is not required, and neither is a requeue required, as VGR is cleaned up and PV/PVC is also cleaned up as required. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
If a PVC was deselected, its label value for CG would revert to an empty string. When reselected, prior to deselection orchestration completion, the label is not updated with the new value. This commit corrects the behaviour for deselected PVCs and retains not updating the label for deleted PVCs that should not get their CG label value updated, as removal of the PVC on delete would be progressing. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
When creating VR or VGR for a PVC, to fetch the SC for the PVC the PVC is looked up in the list of PVCs that need VR protection. The functions to determine SC for PVC most often have a PVC that needs inspection. This also breaks when a PVC is deselected, as it will not be in the list of PVCs that need DR protection. Updating determination of SC for a PVC, that may or may not be in the list of PVCs that need protection, to instead take the PVC itself as a reference. The one condition where a PVC needs to be looked up comes in createVR where the VR name is the same as the PVC. In this case lookup PVCs to protect and pass the same for SC determination. Overall, this corrects getStorageClass to use a PVC to determine what its SC is, and corrects createVR to pass in a PVC to getStorageClass instead of getStorageClass relying on finding the PVC in the list of PVCs to protect. Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
efdd0e3 to
c98ba71
Compare
This was referenced Jun 17, 2025
4 tasks
|
e2e update:
|
ELENAGER
approved these changes
Jun 18, 2025
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.
Implements pvcUnprotectVolGroupRep which removes protection for a PVC when VRG
is Primary and is protected by VGR in a CG.
The unprotection works as follows:
from the CG that it belongs to
As the order ensures that the last action for the PVC is to remove its CG
label, the entire workflow is idempotent across multiple reconcile loops.
Further, all errors/progress is reported into the PVC DataReady condition.
An additional change is made to pvcsUnprotectVolGroupRep to set VRG for requeue
only if reconcileMissingVGR returns a requeue. If it reports a missing VGR and
no requeue, then further processing of the VGR is not required, and neither is
a requeue required, as VGR is cleaned up and PV/PVC is also cleaned up as
required.
Also corrects getStorageClass to use a PVC to determine what
its SC is, and corrects createVR to pass in a PVC to getStorageClass
instead of getStorageClass relying on finding the PVC in the list of
PVCs to protect. Thereby allowing common routines to fetch SC and related
classes given a PVC, even when these are not in the selected PVC lists, addressing
cases where a PVC is deselected.