Bug 1817559

Summary:	Limits not updated
Product:	OpenShift Container Platform	Reporter:	Sergio <sregidor>
Component:	Migration Tooling	Assignee:	Danil Grigorev <dgrigore>
Status:	CLOSED ERRATA	QA Contact:	Xin jiang <xjiang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.4	CC:	chezhang, dymurray, jmatthew, pvauter, rpattath, whu, xjiang
Target Milestone:	---
Target Release:	4.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1817564 (view as bug list)		Environment:
Last Closed:	2020-05-28 11:09:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1817564

Description Sergio 2020-03-26 15:06:57 UTC

Description of problem:
When migrationcontroller resource is edited to redefine the configured limits, the new configured limits are ignored.

Version-Release number of selected component (if applicable):
CAM 1.1.2
OCP 4.2

How reproducible:
Always

Steps to Reproduce:
1. Install CAM using this limit value in the migration controller

mig_namespace_limit: "2"

2. Run a migration of 3 clusters. The migration should be show a Critical Condition preventing the execution.
3. Edit the migrationcontroller limit and use: 

$ oc edit migrationcontroller migration-controller -n openshift-migration
....
mig_namespace_limit: "4"


Actual results:
After setting the new limit to "4" the migration continues blocked with the critical condition.

Expected results:
The new limit should be used, and migrations with 3 namespaces should be allowed.


Additional info:
Whenever we change the limits in migrationcontroller resource, the controller should be redeployed to take the new values. This redeployment is not happening.

Comment 1 Danil Grigorev 2020-04-07 12:34:43 UTC

Was not happening to me on latest. This condition only appears on the MigPlan resource for me, and reproducing those steps resulted in correct behaviour, it just took appr. 1 min.. Could it be that the operator was failing to reconcile and update controller instance?

Comment 2 Zhang Cheng 2020-04-08 02:07:03 UTC

Let's double confirm to see if the original issue still existing in the last 1.2 code.

Comment 3 Danil Grigorev 2020-04-08 10:04:50 UTC

Was able to confirm the issue, and the fix is out there - https://github.com/konveyor/mig-operator/pull/295

Apparently, when the first value in the filters is a single character, the whole join is obsolete, and SHA1 is receiving the same single character no matter what is in the joins. The PR claims to fix it, as cors_origins will never be empty.

Comment 7 Sergio 2020-05-08 14:07:02 UTC

Verified using CAM 1.2 stage

After editing MigrationController resource, changing mig_namespace_limit, the controller pod was restarted using the new limits.

Comment 9 errata-xmlrpc 2020-05-28 11:09:55 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:2326