Conversation
Carthaca
requested review from
chuan137,
crenduchinta88,
kpawar-sap,
skook1 and
sumitarora2786
as code owners
September 7, 2026 09:53
|
can you rebase, py3 would pass. |
Replica create/mount and the periodic replica state update could get stuck when creating a SnapMirror snapshot failed with: Volume Clone Split is in progress on the source volume. wait_for_mount_replica() treated any terminal SnapMirror error as permanent and raised NetAppException immediately, so periodic updates never retried. Separately, update_replica_state() treated any NaApiError from create/resync as STATUS_ERROR, which also stopped automatic recovery once the transient backend condition cleared. Also, for a SnapMirror relationship that is present but still 'uninitialized' (baseline transfer never completed), periodic update called snapmirror resume/resync instead of snapmirror initialize. Per NetApp documentation, resync resynchronizes a previously initialized relationship (e.g. broken-off, or missing a common snapshot); it does not start the baseline transfer. An uninitialized relationship therefore never progressed even after the clone split condition cleared. Add a shared clone-split matcher and: - wait_for_mount_replica(): retry (ShareBusyException) instead of failing fast when the terminal SnapMirror error is caused by a source volume clone split still in progress. - update_replica_state(): keep the replica in REPLICA_STATE_OUT_OF_SYNC (instead of STATUS_ERROR) when create/initialize/resync fails due to the same transient clone split condition, so the next periodic replica state update retries automatically. - update_replica_state(): call snapmirror initialize (not resume/resync) when the relationship is still uninitialized, so it can actually complete its baseline transfer once the source volume clone split finishes. Change-Id: Id8d85400eb2990b455d4fede60c342d7bf62509a Signed-off-by: Maurice Escher <maurice.escher@sap.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Carthaca
force-pushed
the
maurice-escher-sap-netapp-replica-recovery-analysis
branch
from
September 8, 2026 13:55
889c786 to
a459116
Compare
Collaborator
Author
|
I had to retrigger the checks, now they are green :) |
kpawar-sap
approved these changes
Sep 15, 2026
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
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.
Replica create/mount and the periodic replica state update could get
stuck when creating a SnapMirror snapshot failed with:
Volume Clone Split is in progress on the source volume.
wait_for_mount_replica() treated any terminal SnapMirror error as
permanent and raised NetAppException immediately, so periodic updates
never retried. Separately, update_replica_state() treated any
NaApiError from create/resync as STATUS_ERROR, which also stopped
automatic recovery once the transient backend condition cleared.
Also, for a SnapMirror relationship that is present but still
'uninitialized' (baseline transfer never completed), periodic update
called snapmirror resume/resync instead of snapmirror initialize.
Per NetApp documentation, resync resynchronizes a previously
initialized relationship (e.g. broken-off, or missing a common
snapshot); it does not start the baseline transfer. An uninitialized
relationship therefore never progressed even after the clone split
condition cleared.
Add a shared clone-split matcher and:
failing fast when the terminal SnapMirror error is caused by a
source volume clone split still in progress.
REPLICA_STATE_OUT_OF_SYNC (instead of STATUS_ERROR) when
create/initialize/resync fails due to the same transient clone
split condition, so the next periodic replica state update retries
automatically.
resume/resync) when the relationship is still uninitialized, so it
can actually complete its baseline transfer once the source volume
clone split finishes.
Change-Id: Id8d85400eb2990b455d4fede60c342d7bf62509a
Signed-off-by: Maurice Escher maurice.escher@sap.com
Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com