Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I manually added an data spec.rsync_opt_extras="--fake-option" to MigrationController migration-controller, and then the date was written into CM migration-controller. Minutes later, delete it from MigrationController migration-controller, it was not deleted from CM migration-controller even waited more than 10 mins. Version-Release number of selected component (if applicable): MTC 1.4.2 controller image: registry.redhat.io/rhmtc/openshift-migration-controller-rhel8@sha256:f02f9a62479b9ec712c622880128a80dafb5e034a97df6c34fc14cf0c0699f21 How reproducible: always Steps to Reproduce: 1. Configure a wrong option for the rsync configuration on controller host $ oc patch -n openshift-migration MigrationController migration-controller --type=json -p='[{"op":"add", "path": "/spec/rsync_opt_extras", "value": "--fake-option"}]' 2. wait a moment and the migration controller pod is restarted 3. Check CM migration-controller and spec.rsync_opt_extras="--fake-option" is added into CM migration-controller $ oc -n openshift-migration get cm migration-controller -o yaml apiVersion: v1 data: CLIENT_POD_CPU_LIMIT: "1" CLIENT_POD_CPU_REQUEST: 400m CLIENT_POD_MEMORY_LIMIT: 1Gi CLIENT_POD_MEMORY_REQUEST: 1Gi CORS_ALLOWED_ORIGINS: (?i)//migration-openshift-migration\.apps\.cam-tgt-16030\.qe\.devcluster\.openshift\.com(:|\z) //127.0.0.1(:|$) //localhost(:|$) ENABLE_DVM_PV_RESIZING: "False" ENABLE_INTELLIGENT_PV_RESIZE: "True" NAMESPACE_LIMIT: "10" POD_LIMIT: "100" PV_LIMIT: "100" RSYNC_OPT_EXTRAS: --fake-option STUNNEL_POD_CPU_LIMIT: "1" STUNNEL_POD_CPU_REQUEST: 400m STUNNEL_POD_MEMORY_LIMIT: 1Gi STUNNEL_POD_MEMORY_REQUEST: 1Gi TRANSFER_POD_CPU_LIMIT: "1" TRANSFER_POD_CPU_REQUEST: 400m TRANSFER_POD_MEMORY_LIMIT: 1Gi TRANSFER_POD_MEMORY_REQUEST: 1Gi WORKING_DIR: /var/cache/discovery kind: ConfigMap 4. Delete spec.rsync_opt_extras from MigrationController and wait controller is restarted Actual results: Check CM migration-controller and spec.rsync_opt_extras="--fake-option" still exist in CM migration-controller $ oc -n openshift-migration get cm migration-controller -o yaml apiVersion: v1 data: CLIENT_POD_CPU_LIMIT: "1" CLIENT_POD_CPU_REQUEST: 400m CLIENT_POD_MEMORY_LIMIT: 1Gi CLIENT_POD_MEMORY_REQUEST: 1Gi CORS_ALLOWED_ORIGINS: (?i)//migration-openshift-migration\.apps\.cam-tgt-16030\.qe\.devcluster\.openshift\.com(:|\z) //127.0.0.1(:|$) //localhost(:|$) ENABLE_DVM_PV_RESIZING: "False" ENABLE_INTELLIGENT_PV_RESIZE: "True" NAMESPACE_LIMIT: "10" POD_LIMIT: "100" PV_LIMIT: "100" RSYNC_OPT_EXTRAS: --fake-option STUNNEL_POD_CPU_LIMIT: "1" STUNNEL_POD_CPU_REQUEST: 400m STUNNEL_POD_MEMORY_LIMIT: 1Gi STUNNEL_POD_MEMORY_REQUEST: 1Gi TRANSFER_POD_CPU_LIMIT: "1" TRANSFER_POD_CPU_REQUEST: 400m TRANSFER_POD_MEMORY_LIMIT: 1Gi TRANSFER_POD_MEMORY_REQUEST: 1Gi WORKING_DIR: /var/cache/discovery kind: ConfigMap Expected results: spec.rsync_opt_extras should be removed from CM migration-controller Additional info:
It also happens when we configure in the migration controller the value of: mig_pv_move_storageclasses When we remove "mig_pv_move_storageclasses" from the migration controller custom resource, the configured storage classes can be moved anyway and the pod environment variables in the pod's yaml are not removed. If that happens, a workaround is to delete the migration-controller deployment, and let the operator to re-create it from scratch.
Verified using MTC 1.5.0 openshift-migration-rhel7-operator@sha256:00e77706ca22bcb557d13c16822180fc877e6ea1639a72fda8eb9f5488b039a2 After removing the attribute from the migrationcontroller resource, it is removed from the migration-controller config map and the migration-controller pod is restarted. Moved to 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 (Migration Toolkit for Containers (MTC) image release advisory 1.5.0), 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-2021:2929