Set or update peerClasses for VRG #1638
Open
Conversation
This file contains 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
The function to createVRGManifestWork will create a new VRG when a ManifestWork for it does not exist. Ensure that the MW is not present before creating one, and return an Exists error for callers to process if one exists. The function ensureVRGManifestWork is to ensure ManifestWork for VRG exists and update its mutable fields appropriately. Added a latch to ensure that the MW for VRG that needs to be ensured is present, and that it is reported as delivered to the ManagedCluster (using a check to see if a view is present). The changes to ensureVRGManifestWork also includes NOT creating a VRG from a view, as that should be ensured by the adoptOrphanVRG function at the start of reconciling a DRPC. The caller startDeploying, which calls createVRGManifestWork, now checks for an exists error and proceeds to update the Placement. This is done as any errors in updating placement would send the reconciler back to creating the VRG, which as it exists would keep failing. Other callers ensure that the VRG exists and if so update it, rather than calling create. Signed-off-by: Shyamsundar Ranganathan <[email protected]>
Update works to ensure VRG is updated with peerClasses that it requires, based on reported PVCs that the VRG is attempting to protect. If a VRG is attempting to protect a PVC for which is is lacking a peerClass and that is available as part of the DRPolicy its peerClasses are updated. For existing peerClasses the VRG information is not updated, this is done to avoid any protection mechanism conflicts. For example, if a VRG carried a peerClass without the replicationID (ie it would choose to protect the PVC using Volsync and VolumeSnapshots), then it is not updated with a peerClass that NOW supports native VolumeReplication, as that would void existing protection. To change replication schemes a workload needs to be DR disabled and then reenabled to catch up to the latest available peer information for an SC. Signed-off-by: Shyamsundar Ranganathan <[email protected]>
BenamarMk
approved these changes
Nov 4, 2024
ShyamsundarR
commented
Nov 4, 2024
| @@ -150,6 +150,8 @@ func (d *DRPCInstance) createOrUpdateVolSyncDestManifestWork(srcCluster string) | |||
| return ctrlutil.OperationResultNone, err | |||
| } | |||
|
|
|||
| // TODO: Update peerClass from source VRG MW (NOT from view) | |||
There was a problem hiding this comment.
@BenamarMk I still need to address this for Secondary (a separate commit) and then we can look at merging it etc. (just a heads up!)
There was a problem hiding this comment.
@BenamarMk added commit to address the above.
Secondary VRG should carry the same peerClass information as the Primary VRG, such that on action changes that promotes the Secondary to a Primary the same peerClasses are used to recover and protect the PVCs. This commit addresses updating Secondary VRG with Primary VRG peerClasses for async cases when Volsync is in use. Currently VRG as Secondary is created when there are any PVCs protected by Volsync. Once the issue of mixed workloads is addressed, a Secondary VRG would exist for all cases, VolRep and sync DR setups as well. This will ensure that in all cases the Secondary peerClasses are a copy of the Primary. Signed-off-by: Shyamsundar Ranganathan <[email protected]>
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.
Update works to ensure VRG is updated with peerClasses that it requires,
based on reported PVCs that the VRG is attempting to protect. If a VRG
is attempting to protect a PVC for which is is lacking a peerClass and
that is available as part of the DRPolicy its peerClasses are updated.
For existing peerClasses the VRG information is not updated, this is done
to avoid any protection mechanism conflicts. For example, if a VRG
carried a peerClass without the replicationID (ie it would choose to
protect the PVC using Volsync and VolumeSnapshots), then it is not
updated with a peerClass that NOW supports native VolumeReplication, as
that would void existing protection.
To change replication schemes a workload needs to be DR disabled and then
reenabled to catch up to the latest available peer information for an SC.