In an ideal world, every migration would go smoothly, and no problems would ever occur, but reality is far from that. In this resource, we’ll review a few common issues that can happen during this process and how to fix them as they come up. 

Prerequisites:

• None!

In this lesson, you will:

• Learn how to address common errors that happen during the migration process.

Common issues

Issue: Pod CrashLoopBackOff with permission errors

Message: 

Health check failed: (403) Forbidden
User "system:serviceaccount:cert-discovery-app:cert-discovery-sa" cannot list resource "namespaces"

Cause: ClusterRole/ClusterRoleBinding were not backed up (cluster-scoped resources are excluded from namespace backups).

Solution:

1. If you didn't export the role-based access controls in Prerequisites, switch to the source cluster and export now:

   export KUBECONFIG=~/kubeconfig-pm-cluster
   oc get clusterrole cert-discovery-role -o yaml > /tmp/clusterrole-cert-discovery.yaml

2. Next, make sure the binding goes through:

   oc get clusterrolebinding cert-discovery-binding -o yaml > /tmp/clusterrolebinding-cert-discovery.yaml

3. Apply the RBAC on the target cluster as shown in previous steps. 

Issue: Backup storage location shows "Unavailable"

This is likely a problem with S3 connectivity and can be checked this way:

1. Input this command to see the error being produced:

   oc get bsl velero-sample-1  -n openshift-adp

2. Test S3 access:

   aws s3 ls s3://cert-discovery-management-app --region eu-north-1

Issue: Restore stuck in "InProgress"

For this, it would be best to check the Restore resource itself. 

1. Check restore details:

   oc oadp restore describe cert-discovery-app-restore -n openshift-adp

2. Check for errors:

   oc get restore cert-discovery-app-restore -n openshift-adp \
     -o jsonpath='{.status.errors}'

3. Check Velero logs:

   oc logs -n openshift-adp deployment/velero -f

Issue: PVC not binding on target cluster

This is likely related to the storage class. 

1. Check the storage class to check the PVC status:

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster
   
   oc get pvc -n cert-discovery-app
   oc describe pvc cert-discovery-data -n cert-discovery-app

2. Verify storage class exists:

   oc get sc lvms-vg1

Issue: Application route not accessible

In the event of this error, there is one way to investigate it. Check the ingress controller:

export KUBECONFIG=~/kubeconfig-bm-hosted-cluster
# Check route status
oc get route -n cert-discovery-app
oc describe route cert-discovery-route -n cert-discovery-app

# Check service endpoints
oc get endpoints -n cert-discovery-app

# Test from within cluster
oc run test-curl --image=curlimages/curl --rm -it --restart=Never -- \
  curl http://cert-discovery-service.cert-discovery-app.svc/health

Learning path summary

Migrating from older architecture can prove helpful in the long run, and with this learning path, we’ve discovered how smooth of a process it can be for bare metal or Red Hat OpenShift Service on AWS clusters. In the scenario we just covered, the act of moving from standalone to hosted control plane clusters would have resulted in fewer nodes required to run the same workloads. This, in turn, saves on the costs necessary to run everything. 

Ready to learn more?

If you're interested in learning more about Red Hat OpenShift, search the Red Hat OpenShift learn hub or try the following learning paths.

• Foundations of OpenShift
• Windows failover clustering in Red Hat OpenShift Virtualization using SCSI-3 persistent reservations
• How to deploy full-stack JavaScript applications in OpenShift