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:

Procedure

  1. 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:
    1. Upgrade operator logs: 
      kubectl logs <upgrade_operator_pod> -n <namespace>
    2. Apiconnect operator logs: 
      kubectl logs <apiconnect_operator_pod> -n<namespace>
    3. Portal upgradefromv2018 CR description: 
      kubectl describe upgradefromv2018.portal <name> -n <namespace>
    4. Portal restore CR description (if present): 
      kubectl describe portalrestore <subsystem_name> -n <namespace>
    5. Portal v10 subsystem CR description (if present): 
      kubectl describe ptl <subsystem_name> -n <namespace>
    6. 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>
  2. Specify the rollback in the upgrade CR:
    1. Edit the upgrade CR:
      kubectl edit UpgradeFromV2018.portal <name> -n <namespace>
    2. Set triggerRollback:
      triggerRollback: true
  3. Monitor the progress of the rollback operation:
    • Check the current status of the upgrade CR:
      kubectl describe upgradefromv2018.portal <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.

  4. Once the rollback has completed you can delete the upgrade CR: 
    kubectl delete upgradefromv2018.portal <name> -n <namespace>