Description of problem: If we create two plans. The first one with persistent volumes, and the second one without them. The second plan will show the volumes of the first plan. If the second one has volumes too, the volumes displayed when creating the second plan are the volumes belonging to the first plan. Version-Release number of selected component (if applicable): OCP3 oc v3.11.126 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https:// openshift v3.11.104 kubernetes v1.11.0+d4cacc0 OCP4 $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.1.0 True False 25h Cluster version is 4.1.0 Controller image: quay.io/ocpmigrate/mig-controller:latest imageID: quay.io/ocpmigrate/mig-controller@sha256:56f0ca2f594a571a7e1dbc35c4ee4b8cc1aed773e0eeb74b32331127a3f95c2d Velero image: quay.io/ocpmigrate/velero:fusor-dev imageID: quay.io/ocpmigrate/velero@sha256:21297a4ab5f82b91bebd5f13d29acb6d43fb87c65ebb1e00fab11ebfeb0a2be2 image: quay.io/ocpmigrate/migration-plugin:latest imageID: quay.io/ocpmigrate/migration-plugin@sha256:7cd1d4c3e2361a51ce7e13d184dff79cd451dd9e05bac8f03d09df80410c4583 UI: image: quay.io/ocpmigrate/mig-ui:latest imageID: quay.io/ocpmigrate/mig-ui@sha256:94c28ae24865174480b92e4a62bf5e886e94c6f3236ec84a1f80f9bd3b044f6a How reproducible: always Steps to Reproduce: 1. Create two project one with volumes and one without volumes oc new-project with-volumes oc new-app mysql-persistent oc new-project without-volumes oc new-app mysql-ephemeral 2. Create a migration plan to migrate the project "with-volumes" (do not execute the migration, just create the plan) 3. Create a migration plan to migrate the project "without-volumes" Actual results: 1. The migration plan for "without-volumes" will show the volumes of the project "with-volumes" in the volumes list. 2. The migration plan for "without-volumes" crashes and redirect the user to a blank screen. Expected results: 1. No volumes should be displayed for "without-volumes" project migration plan. 2. The plan should not crash. Additional info: If the second plan has volumes too, the volumes displayed for the second plan are the ones belonging to the first plan, and crashes too, redirecting to a blank screen.
Related to https://github.com/fusor/mig-ui/issues/481
Likely fixed in below https://github.com/fusor/mig-ui/pull/482
(In reply to John Matthews from comment #2) > Likely fixed in below > https://github.com/fusor/mig-ui/pull/482 I still see the problem in my recent deployments. For instance, I've seen it today in image: quay.io/ocpmigrate/mig-ui:stable imageID: quay.io/ocpmigrate/mig-ui@sha256:f38a52d944227cb7b9e7e175a2dc0df0ae032fd67cdffd8f11a9c4d73855153d
I will take a look at this today
I am not seeing this problem in my local dev environment
Hello, stable version was way too old. I can confirm that this bug is solved in imagePullSecrets: image: quay.io/ocpmigrate/mig-ui:latest imageID: quay.io/ocpmigrate/mig-ui@sha256:315cd7b614eb439a426d7707200c99caeb3ea6c6b08a78b12ea4902c9adb671a
Verified in: imagePullSecrets: image: quay.io/ocpmigrate/mig-ui:latest imageID: quay.io/ocpmigrate/mig-ui@sha256:315cd7b614eb439a426d7707200c99caeb3ea6c6b08a78b12ea4902c9adb671a
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/RHBA-2019:2922