Bug 1925358 - Restic pod does not restart during IDVM migration from OCP 3.9
Summary: Restic pod does not restart during IDVM migration from OCP 3.9
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Migration Toolkit for Containers
Classification: Red Hat
Component: Controller
Version: 1.4.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 1.4.2
Assignee: Pranav Gaikwad
QA Contact: Xin jiang
Avital Pinnick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-05 01:50 UTC by whu
Modified: 2021-03-15 08:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-15 08:15:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github konveyor mig-controller pull 975 0 None open Bug 1925358: Add RestartRestic phase back to itineraries 2021-03-01 16:56:45 UTC
Github konveyor mig-controller pull 976 0 None open Bug 1925358: add RestartRestic phase back to itineraries (#975) 2021-03-01 17:29:05 UTC
Red Hat Product Errata RHBA-2021:0814 0 None None None 2021-03-15 08:15:54 UTC

Description whu 2021-02-05 01:50:00 UTC
Description of problem:
Run a common indirect volume migration from ocp3.9 to ocp 4.7 cluster, the restic pod did not restart during migration. But the restic pods should be restarted. 

Version-Release number of selected component (if applicable):
MTC 1.4.0
image: registry.redhat.io/rhmtc/openshift-migration-rhel7-operator@sha256:085a42a4bdf32cd0ae12cb5af17d6ee6274a577a67298708a2eff3220e08fc23
source cluster: AWS OCP 3.9
target cluster: AWS OCP 4.7  (controller)

How reproducible:
Always

Steps to Reproduce:
1. create a common application in source cluster, such like nginx
oc process -p LOGS_ACCESSMODE=ReadWriteOnce  -p LOGS_STORAGECLASS=gp2  -p HTML_ACCESSMODE=ReadWriteOnce  -p HTML_STORAGECLASS=gp2 -p namespace=ocp-22222-nginx -f https://gitlab.cee.redhat.com/app-mig/cam-helper/raw/master/ocp-24706/nginx_with_pv_template.yml  | oc create -f -
2. create migplan as nornal with indrect volume migration mode
3. trigger migration

Actual results:
The restic pod did not restart during migration

Expected results:
The restic pod should be restarted during migration

Additional info:
$ oc get migcluster source-cluster -o yaml
spec:
  exposedRegistryPath: docker-registry-default.apps.0203-cok.qe.rhcloud.com
  insecure: true
  isHostCluster: false
  serviceAccountSecretRef:
    name: sa-token-source-cluster
    namespace: openshift-migration
  url: https://ec2-34-235-121-235.compute-1.amazonaws.com:8443

Comment 2 Pranav Gaikwad 2021-02-25 18:31:12 UTC
I confirmed that the Restic Pods are not being restarted on OpenShift 3.7 & 3.9

This is due to a regression introduced in 1.4.0 when we added Velero stale backup/restore cleanup logic. I have tested a fix to resolve this issue but I'd like to confirm with Derek (he originally worked on Velero cleanup) that my change doesn't affect any of the new logic thats in place for removing stale Velero state.

Comment 7 Sergio 2021-03-05 16:17:48 UTC
Verified using MTC 1.4.2

openshift-migration-rhel7-operator@sha256:7ef3e0373302290880469269d34b8caa771d420848ed448a8b11280416328669
    - name: MIG_CONTROLLER_REPO
      value: openshift-migration-controller-rhel8@sha256
    - name: MIG_CONTROLLER_TAG
      value: f02f9a62479b9ec712c622880128a80dafb5e034a97df6c34fc14cf0c0699f21

Run test case ocp-31355-restartrestic-37-39

Moved to VERIFIED status.

Comment 11 errata-xmlrpc 2021-03-15 08:15:36 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 (Migration Toolkit for Containers (MTC) image release advisory 1.4.2), 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-2021:0814


Note You need to log in before you can comment on or make changes to this bug.