Description of problem: When the remote migcluster lost connection due to some reason, for instance re-install the MTC in the remote cluster. Then try to update the existing miglucster with new sa token, but it cannot update it with new sa token. Version-Release number of selected component (if applicable): MTC 1.4.2 How reproducible: Always Steps to Reproduce: 1. set up 2 clsuters and install MTC, I suppose mig controller is installed on the target cluster 2. delete the MTC on the source cluster 3. Install the MTC on the source cluster 4. try to update sa token of migration-controller with the new one Actual results: it cannot store the new sa token into remote migcluster. The root cause is that the secret (sa-token-source-cluster) is under openshift-migration namespace, instead of openshift-config namespace. when clicking update, it's trying to store it to the openshift-config namespace. Expected results: it should be able to update the remote migcluster with new sa token. Additional info:
I think this bug is fixed, I can no longer reproduce the issue. Guessing Pranav resolved it when doing testing on change of SA token for client caching work in https://github.com/konveyor/mig-controller/pull/1037, and Ian may have fixed UI related parts around waiting to update status of MigCluster until changes are made in modal.
hello, sorry the below bug description is not accurate .if you add remote cluster from MTC console, the secret (sa-token-source-cluster) will be stored under openshift-config namespace. that’s why you cannot reproduce it if you added remote cluster from console it cannot store the new sa token into remote migcluster. The root cause is that the secret (sa-token-source-cluster) is under openshift-migration namespace, instead of openshift-config namespace. the secret (sa-token-source-cluster) should be checked on target cluster. as we use scripts to add remote cluster, so the secret (sa-token-source-cluster) is stored under openshift-migration namespace.
We dug into this and will only trigger an issue if 1) you have created a MigCluster with a secret.namespace value that differs from openshift-config and 2) you try to edit that via the UI. Given the very low probability of anyone hitting this, I can't consider this a blocker. We're past the blockers only milestone, so I'm going to put this on our next release.
This bug should be fixed with the merge of https://github.com/konveyor/mig-ui/pull/1268
Verfied using SOURCE CLUSTER: AWS OCP 3.11 (MTC 1.5.1) NFS TARGET CLUSTER: AWS OCP 4.9 (MTC 1.6.0) OCS4 openshift-migration-rhel8-operator@sha256:ef00e934ed578a4acb429f8710284d10acf2cf98f38a2b2268bbea8b5fd7139c - name: MIG_CONTROLLER_REPO value: openshift-migration-controller-rhel8@sha256 - name: MIG_CONTROLLER_TAG value: 27f465b2cd38cee37af5c3d0fd745676086fe0391e3c459d4df18dd3a12e7051 - name: MIG_UI_REPO value: openshift-migration-ui-rhel8@sha256 - name: MIG_UI_TAG value: 558d4723e2a0e5e9c337062ec2dd27c52f9f3865a6e1847b26345e757c4356fe Moved to VERIFIED status.
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: Migration Toolkit for Containers (MTC) 1.6.0 security & bugfix 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-2021:3694