Bug 2218487 - [MDR][Fusion] PVC remain in pending state after successful failover
Summary: [MDR][Fusion] PVC remain in pending state after successful failover
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: odf-dr
Version: 4.13
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: ODF 4.13.1
Assignee: Shyamsundar
QA Contact: Parikshith
URL:
Whiteboard:
Depends On:
Blocks: 2223553
TreeView+ depends on / blocked
 
Reported: 2023-06-29 10:55 UTC by pallavi
Modified: 2023-08-09 17:00 UTC (History)
8 users (show)

Fixed In Version: 4.13.1-9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2223553 (view as bug list)
Environment:
Last Closed: 2023-08-02 16:07:42 UTC
Embargoed:


Attachments (Terms of Use)
Ramen Artifacts (1.37 MB, application/zip)
2023-07-05 11:20 UTC, pallavi
no flags Details
Ramen-Screenshots (195.30 KB, application/zip)
2023-07-05 11:30 UTC, pallavi
no flags Details
PersistentVolumes-SourceAndTargetClusters (32.41 KB, application/zip)
2023-07-05 12:49 UTC, pallavi
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github RamenDR ramen issues 943 0 None closed PVC remain in pending state after successful failover 2023-07-18 07:55:58 UTC
Github RamenDR ramen pull 972 0 None Merged Set ClusterDataReady false if PV exists, is bound, and claim's deletion timestamp is non-zero 2023-07-18 07:56:45 UTC
Github red-hat-storage ramen pull 116 0 None open Bug 2218487: Set ClusterDataReady false if PV exists, is bound, and claim's deletion timestamp is non-zero 2023-07-18 11:56:06 UTC
Red Hat Product Errata RHSA-2023:4437 0 None None None 2023-08-02 16:08:03 UTC

Description pallavi 2023-06-29 10:55:32 UTC
Description of problem (please be detailed as possible and provide log
snippests):
This issue is reproducible while using metrodr offering of ibm-spectrum-fusion product.
Steps to reproduce: 
Initiate failover of an application on cluster where earlier PVCs in terminating state which is needed while changing ReplicationState of vrg to secondary.
After successful failover, PVCs in pending state.
Observed that UID field of PV in 'ClaimRef' not refreshed.

Info about fusion relocation workflow:
As a part of fusion 'relocation' workflow, before starting relocation on new cluster, VRG ReplicationState on older cluster is updated as 'secondary' and PVCs are also marked for deletion.
When failback is initiated again on older cluster (for application relocated to new cluster), older vrg(having secondary ReplicationState) is deleted and new vrg is created. Along with older vrg, PVC also gets automatically deleted since its already marked for deletion.
Before starting failback on given cluster where we faced PVC pending issue, following was VRG and PVC status

VRG having ReplicationState as secondary
PVCs in terminating state.
After failback, older vrg got deleted, new vrg created successfully and PVC was in pending state. Corresponding PV's claim Ref field which stores PVC uid was not identical as that of new PVC which was in pending state(indicating its not refreshed)




Version of all relevant components (if applicable): 


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)? yes


Is there any workaround available to the best of your knowledge? 


Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)? 1 


Can this issue reproducible? yes


Can this issue reproduce from the UI? yes


If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. Initiate failover of an application on cluster where earlier PVCs in terminating state which is needed while changing ReplicationState of vrg to secondary.
2. After successful failover, PVCs in pending state.
3. Observed that UID field of PV in 'ClaimRef' not refreshed.
Actual results: PVC remains in pending state


Expected results: PVC should be bound to correct PV


Additional info: This bug is reproduced in MetroDR service of ibm-spectrum-fusion product

Comment 5 pallavi 2023-07-05 11:20:09 UTC
Created attachment 1974090 [details]
Ramen Artifacts

Comment 6 pallavi 2023-07-05 11:30:40 UTC
Created attachment 1974091 [details]
Ramen-Screenshots

Comment 7 pallavi 2023-07-05 12:49:44 UTC
Created attachment 1974134 [details]
PersistentVolumes-SourceAndTargetClusters

Comment 9 Harish NV Rao 2023-07-18 06:48:39 UTC
QE is acking this BZ for 4.13.1 based on the test plan - https://docs.google.com/document/d/1zg120opbyDgkcRM0rY5HA1T4gRCsF-zEk0TNEI1T8eY/edit

Comment 22 errata-xmlrpc 2023-08-02 16:07:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat OpenShift Data Foundation 4.13.1 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:4437


Note You need to log in before you can comment on or make changes to this bug.