Bug 1757571 - EnsureCloudSecretPropagated step hangs if src and dest clusters are both remote
Summary: EnsureCloudSecretPropagated step hangs if src and dest clusters are both remote
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Migration Tooling
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.3.0
Assignee: Scott Seago
QA Contact: Xin jiang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-01 20:06 UTC by Scott Seago
Modified: 2023-03-24 15:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-06 20:20:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:0440 0 None None None 2020-02-06 20:20:55 UTC

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


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