Bug 1757571

Summary: EnsureCloudSecretPropagated step hangs if src and dest clusters are both remote
Product: OpenShift Container Platform Reporter: Scott Seago <sseago>
Component: Migration ToolingAssignee: Scott Seago <sseago>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: dahernan, dymurray, jmatthew, xjiang
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-06 20:20:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Scott Seago 2019-10-01 20:06:12 UTC
Description of problem:
If the controller is running on a cluster which is not the source or target of an open migplan, the controller cluster won't have a copy of the velero cloud secret. Currently the controller is comparing the mounted velero secret (in src or dest cluster) with the velero cloud secret kubernetes resource in the controller cluster. If the controller happens to be a src or destination cluster for the migplan, this will work fine. If it does not belong to any open migplan, or it belongs to a migplan which is associated with a different secret, then these may not match and the EnsureCloudSecretPropagated phase will hang forever.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a migplan with one cloud secret that references the controller cluster as src or destination.
2. Close the migplan.
3. Create a new migplan with src and dest clusters that are both remote (i.e. neither is the same cluster running the controller). For this migplan, use a migstorage resource which contains a *different* cloud credentials secret. Make sure the *content* of the secret is different rather than just a separate secret resource with equivalent contents.
4. Runn a migration on this migplan. It won't get past the EnsureCloudSecretPropagated stage.

Actual results:
Migration stuck at EnsureCloudSecretPropagated

Expected results:
Migration succeeds.

Additional info:

Comment 1 Scott Seago 2019-10-01 20:07:11 UTC
Fix is here: https://github.com/fusor/mig-controller/pull/335

The fix is to use the reference'd cluster's client rather than the controller client.

Comment 4 Xin jiang 2020-01-15 09:49:47 UTC
verified.

Comment 6 errata-xmlrpc 2020-02-06 20:20:44 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, 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/RHEA-2020:0440