Bug 1867597

Summary: Stage pods should not be sourced from deprecated registry.access.redhat.com
Product: OpenShift Container Platform Reporter: Erik Nelson <ernelson>
Component: Migration ToolingAssignee: Jason Montleon <jmontleo>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4CC: chezhang, dwhatley, ernelson, jmatthew, pvauter, rjohnson, sregidor, sseago, vpagar, whu, xjiang
Target Milestone: ---Flags: jmontleo: needinfo+
Target Release: 4.4.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1870135 (view as bug list) Environment:
Last Closed: 2020-08-26 08:27: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: 1870135    
Bug Blocks:    

Description Erik Nelson 2020-08-10 12:58:50 UTC
Description of problem:
Currently the stage pods are hardcoded to pull from registry.access.redhat.com, which has been deprecated in favor of registry.redhat.io.

This has been raised as a problem by a customer who only has whitelisted registry.redhat.io; they are unable to pull from registry.access.redhat.com.

https://www.redhat.com/en/blog/transitioning-red-hat-container-registry

Relevant controller source:
https://github.com/konveyor/mig-controller/blob/master/pkg/controller/migmigration/stage.go#L571
https://github.com/konveyor/mig-controller/blob/master/pkg/controller/migmigration/stage.go#L610

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

How reproducible:
Every time

Comment 2 Jason Montleon 2020-08-10 13:43:06 UTC
Looks like registry.redhat.io/rhel7 also exists (if we can maybe we should switch to ubi8, but that's a separate discussion).

Perhaps we pass the REGISTRY env var we set on the operator to the controller container and use that as the registry prefix here?

CC'ing Scott and Derek for their input since this is more their expertise.

Comment 13 Sergio 2020-08-20 16:28:11 UTC
Verified using CAM 1.2.5 stage

openshift-migration-rhel7-operator@sha256:493e56a8b609eadad79d2df8e3c6402b2014ebcb645a939fa34004b056ea1a2e


We have configured in the migrationcontroller resource this values for stage and registry pods 

    migration_registry_image: docker.io/registry
    migration_registry_repo: registry
    migration_registry_version: 2
    migration_stage_version: 44f0362c8570d707582bd428aaf18f390ce915ef72cdeb60cf2699171dbda3c8 (non default one)
    velero_restic_restore_helper_version: 44f0362c8570d707582bd428aaf18f390ce915ef72cdeb60cf2699171dbda3c8 (non default one)

We did it in target cluster, and in source cluster, and we could verify that the values used were the right ones in the right clusters, that the migration-cluster-config configmap was updated and that everything was working fine in migrations with pvcs and internal images (cakephp application).


We move the status to VERIFIED.

Comment 14 Sergio 2020-08-20 16:45:41 UTC
We verified too that the file /operator.yml inside the operator pod points to the right registry registry.redhat.io

and that this variables define the content of the configmap and the image used for the stage pod
    migration_stage_image: XXXXXXX
    migration_stage_repo: XXXXXX
    migration_stage_version: XXXXXXXXX

Comment 16 errata-xmlrpc 2020-08-26 08:27: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 (Cluster Application Migration (CAM) Tool Image Release Advisory 1.2.5), 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-2020:3535