Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1779289

Summary: Simultaneous CORS configuration for OCP4.1 and OCP4.2 in CAM Operator causes UI failure
Product: OpenShift Container Platform Reporter: Erik Nelson <ernelson>
Component: Migration ToolingAssignee: Danil Grigorev <dgrigore>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: apinnick, chezhang, dgrigore, ernelson, jmatthew, sregidor, tapatel
Target Milestone: ---   
Target Release: 4.2.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 1762938 Environment:
Last Closed: 2019-12-19 15:44:27 UTC Type: ---
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: 1762938    
Bug Blocks:    

Description Erik Nelson 2019-12-03 16:58:26 UTC 
+++ This bug was initially created as a clone of Bug #1762938 +++

Description of problem:
[openshift-migration] CORS configuration for OCP4.1 and OCP4.2 should never be able to simultaneously configured

Version-Release number of selected component (if applicable):
4.3

How reproducible:
Everytime

Steps to Reproduce:
1) Install migration operator and controller on OCP3.11 and OCP42 using : https://github.com/fusor/mig-operator/#mig-operator

2) Configure CORS using : https://github.com/fusor/mig-operator/#manual-cors-cross-origin-resource-sharing-configuration

3) Get mig-url using : oc get route -n openshift-migration

4) Launch mig-url from step3 and login using cluster credential. Mig-UI failed to launch with oauth token issue.

Actual results:
Mig-UI failed to launch

Expected results:
Mig-UI should launch


Additional info:
Erik Nelson Comment on Slack : 
@jmontleo he had the 4.2 setting configured on the apiserver.config, as well as the cors configuration in the unsupportedConfigOverrides section on the kubeapiserver.operator and authentication.operator. Both of them saw the unsupported option and went into a bad state. I think the solution here is that these are mutually exclusive, and that usupportedConfigOverrides should never be set if we're using the proper API.

I just want to make sure this isn't something that's happening with normal operation on 4.2 clusters
launching a cluster to confirm this now

--- Additional comment from Erik Nelson on 2019-10-17 20:45:59 UTC ---

Investigated this further and confirmed the operator correctly configures the correct version of corsAllowedOrigins under normal circumstances. The suspicion here is that the unsupportedConfig was manually configured, while the operator configured 4.2 as you would expect. It would be good to have the operator enforce that only ONE of these configuration methods is ever employed at any given time.
Comment 1 Erik Nelson 2019-12-10 19:08:11 UTC 
https://github.com/fusor/mig-operator/pull/180
Comment 4 Sergio 2019-12-18 19:26:42 UTC 
Verified in 1.0.1 osbs images.

We get the Critical condition in the MigrationController resource claiming that the CORS has inconsistent configuration.

apiVersion: v1
items:
- apiVersion: migration.openshift.io/v1alpha1
  kind: MigrationController
  metadata:
    creationTimestamp: "2019-12-18T19:22:23Z"
    generation: 2
    name: migration-controller
    namespace: openshift-migration
    resourceVersion: "645117"
    selfLink: /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migrationcontrollers/migration-controller
    uid: b7b04e40-21cb-11ea-9610-02b229d0f822
  spec:
    azure_resource_group: ""
    cluster_name: host
    mig_namespace_limit: "10"
    mig_pod_limit: "100"
    mig_pv_limit: "100"
    migration_controller: true
    migration_ui: true
    migration_velero: true
    olm_managed: true
    restic_timeout: 1h
    version: 1.0 (OLM)
  status:
    conditions:
    - message: Unexpected CORS configuration for kubeapiserver
      reason: CorsMisConfigured
      status: "True"
      type: Critical
    phase: Reconciling
Comment 6 errata-xmlrpc 2019-12-19 15:44:27 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-2019:4304