Bug 1831711

Summary: GVK incompatibility reported in compatible resources
Product: OpenShift Container Platform Reporter: Sergio <sregidor>
Component: Migration ToolingAssignee: Derek Whatley <dwhatley>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: high Docs Contact:
Priority: high    
Version: 4.4CC: chezhang, dymurray, ernelson, jmatthew, pvauter, rjohnson, 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: 1831705 Environment:
Last Closed: 2020-05-28 11:10:47 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: 1831705    
Bug Blocks:    

Description Sergio 2020-05-05 14:15:23 UTC
+++ This bug was initially created as a clone of Bug #1831705 +++

Description of problem:
When we create resources using apps/v1 endpoint in ocp4.2 and we want to migrate them to ocp4.4, the migration shows a warning saying that those resources cannot be migrated because they are incompatible with ocp4.4 because they use extensions/v1beta1  and apps/v1beta2 endpoints.

Version-Release number of selected component (if applicable):
SOURCE CLUSTER: 4.2
TARGET CLUSTER: 4.4
KONVEYOR 1.2

How reproducible:
Always

Steps to Reproduce:
1. In source cluster create a deployment using apps/v1 endpoint. For instance:

oc new-project hello-openshift

cat <<EOF | oc create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80
EOF

2. Create a migration plan to migrate this namespace

Actual results:
The migration plan says that there are resources in this namespaces that cannot be migrated because they use extensions/v1beta1  and apps/v1beta2 endpoints. Nevertheless, the resource that we have created actually uses apps/v1 endpoint.

  status:
    conditions:
    - category: Warn
      lastTransitionTime: "2020-05-05T08:39:15Z"
      message: 'Some namespaces contain GVKs incompatible with destination cluster.
        See: `incompatibleNamespaces` for details'
      status: "True"
      type: GVKsIncompatible
    - category: Required
      lastTransitionTime: "2020-05-05T08:39:16Z"
      message: The `persistentVolumes` list has been updated with discovered PVs.
      reason: Done
      status: "True"
      type: PvsDiscovered
    - category: Required
      lastTransitionTime: "2020-05-05T08:39:18Z"
      message: The storage resources have been created.
      status: "True"
      type: StorageEnsured
    - category: Required
      lastTransitionTime: "2020-05-05T08:39:20Z"
      message: The migration registry resources have been created.
      status: "True"
      type: RegistriesEnsured
    - category: Required
      lastTransitionTime: "2020-05-05T08:39:20Z"
      message: The migration plan is ready.
      status: "True"
      type: Ready
    incompatibleNamespaces:
    - gvks:
      - group: extensions
        kind: deployments
        version: v1beta1
      - group: extensions
        kind: replicasets
        version: v1beta1
      - group: apps
        kind: deployments
        version: v1beta2
      - group: apps
        kind: replicasets
        version: v1beta2
      - group: apps
        kind: deployments
        version: v1beta1
      name: hello-openshift


Expected results:
The namespace and its resources should be migrated without problems.

Additional info:

when I get the resource, it's true that by default it's shown as v1beta1. But it actually is a v1 deployment

$ oc get deployments -o yaml | grep "\- apiVer"
- apiVersion: extensions/v1beta1
$ oc get deployments.apps -o yaml | grep "\- apiVer"
- apiVersion: apps/v1

This issue may explain what happens in the cluster
https://github.com/kubernetes/kubernetes/issues/58131

Comment 1 John Matthews 2020-05-06 18:11:34 UTC
*** Bug 1831705 has been marked as a duplicate of this bug. ***

Comment 2 Derek Whatley 2020-05-12 14:13:19 UTC
A fix for this BZ was developed in two pieces which have been merged to mig-controller master and cherry-picked to the release-1.2.0 branch.

The next downstream build is planned for Wednesday May 13, at which point QA should be able to verify this is resolved.

PRs:
https://github.com/konveyor/mig-controller/pull/530
https://github.com/konveyor/mig-controller/pull/534

Cherry-picks:
https://github.com/konveyor/mig-controller/commit/4aa0e30e47589d97fe29db57818a1b64331b4372
https://github.com/konveyor/mig-controller/commit/ffd00ff404383b23fb3ecf2b42092d4906e401e2

Comment 3 Derek Whatley 2020-05-12 15:38:20 UTC
Marked as ON_QA by mistake, should have been POST.

Comment 8 Xin jiang 2020-05-15 08:19:58 UTC
verified in CAM 1.2.

 image: quay-enterprise-quay-enterprise.apps.qe-appmig-tgt-3630.qe.devcluster.openshift.com/admin/openshift-migration-controller-rhel8@sha256:5e81446f66905bbb4ce48a55430050d5df469137834c444f37fa1a68a1e6b3c7

Comment 10 errata-xmlrpc 2020-05-28 11:10:47 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