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:
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.
verified.
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