Rolling back Developer Portal to v2018

If problems are encountered during the upgrade of Developer Portal to v10, you can rollback to v2018.

About this task

The rollback process removes any v10 portal related resources and reinstates the v2018 resources. During rollback:

The v2018 ingress resources are recreated.
The v2018 portal www and db pods are unfrozen.
Once the pods have come back up and reached READY status, any remaining portal upgrade related resources are removed.

If a portal upgrade CR has been rolled back, then in order to retry the upgrade a new portal upgrade CR must be created. It is recommended to delete the failed upgrade CR instance first.

The upgrade CR property triggerRollback provides the ability to define when a rollback should or should not be initiated. The triggerRollback property can take the following values:

Value	Description
`false`	Rollback of the portal subsystem will not be triggered. Default value
`true`	The upgrade of the portal subsystem will be rolled back immediately unless the upgrade process has already started to remove the v2018 portal resources, as indicated by the status condition `CleanupInProgress` is true. The upgrade CR is rejected if `triggerRollback` is set to `true` on creation.

You should gather log information before editing the upgrade CR and setting the triggerRollback value to true, as follows:

Note: For OpenShift users: The steps that are detailed in this topic use the Kubernetes kubectl command. On OpenShift, use the equivalent oc command in its place. If you are using a top-level CR you must edit the multiSiteHA section for the subsystem in the top-level CR, instead of directly in the subsystem CRs. If the subsystem section is not included in the top-level CR, copy and paste the section from the subsystem CR to the top-level CR.

Procedure

Prior to setting triggerRollback: true in the upgrade CR, collect the following logs and details, and redirect the output of each to a suitable file location:

Upgrade operator logs:

kubectl logs <upgrade_operator_pod> -n <namespace>

Apiconnect operator logs:

kubectl logs <apiconnect_operator_pod> -n <namespace>

Portal upgradefromv2018 CR description:

kubectl describe up2018p <name> -n <namespace>

Portal restore CR description (if present):

kubectl describe portalrestore <subsystem_name> -n <namespace>

Portal v10 subsystem CR description (if present):

kubectl describe ptl <subsystem_name> -n <namespace>

Portal v10 subsystem pod logs (if present):

Kubectl logs <v10_portal_www> -c [admin/web] -n <namespace>

Kubectl logs <v10_portal_db> -c [db/dbproxy] -n <namespace>

Kubectl logs <v10_portal_nginx> -n <namespace>

Specify the rollback in the upgrade CR:
1. Edit the upgrade CR:
```
kubectl edit up2018p <name> -n <namespace>
```
2. Set triggerRollback:
```
triggerRollback: true
```
Monitor the progress of the rollback operation:
- Check the current status of the upgrade CR:
```
kubectl describe up2018p <name> -n <namespace>
```
- Monitor the activity of the rollback operation by tailing the apiconnect-upgrade-operator pod logs:
```
kubectl logs -f <apiconnect-upgrade-operator-pod-name>
```
Upon completion the upgrade CR will display the status condition Failed.
Once the rollback has completed you can delete the upgrade CR:
```
kubectl delete up2018p <name> -n <namespace>
```