Bug 2316210 - [RDR] Clean up of a complicated Application during RDR Relocate can result in VRG stalemate for new PVC's
Summary: [RDR] Clean up of a complicated Application during RDR Relocate can result in...
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: odf-dr
Version: 4.16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Raghavendra Talur
QA Contact: krishnaram Karthick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-10-02 21:20 UTC by astreit
Modified: 2024-10-16 04:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OCSBZM-9282 0 None None None 2024-10-02 21:20:57 UTC

Description astreit 2024-10-02 21:20:05 UTC
Description of problem (please be detailed as possible and provide log
snippests):
The following problem was specifically encountered during RDR Relocate of a ACM Discovered application, but depending on the accuracy/complexity of the clean up process of an ACM Managed application, it is believed this problem is not specific to Discovered applications.
During RDR Relocate of an ACM Discovered application, when the corresponding DRPC has .status.progression == WaitOnUserToCleanup, the user must "Clean Up" the application to the point where all protected PVCs are deleted in order for VR and VRG finalizers to complete.
In this specific case with an application that leverages multiple Operators/Controllers and corresponding CR's, when the protected PVC's were deleted, some Operator/Controller pods were still running and attempting to reconcile application CR's and either re-created a deleted PVC or created a pod that attempted to mount a deleted PVC while the VR and VRG finalizers were running.  The result was a stalemated VRG with some protected PVC's as Secondary and other protected PVC's are Primary. 

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)?
There is no recovery of the application.

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

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

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
No

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


Steps to Reproduce:
1.
2.
3.


Actual results:


Expected results:


Additional info:

Comment 2 Sunil Kumar Acharya 2024-10-07 13:00:38 UTC
Moving the non-blocker BZs out of ODF-4.17.0. If you believe this is a blocker issue, please feel free to propose it back to ODF-4.17.0 as blocker with justification note.


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