Rolling back from v5.2

This section guides you on how to roll back from Adeptia Automate v5.2 to Adeptia Automate v5.1, AC v4.7.1, AC v4.7, or AC v4.6.

	This rollback guide is applicable only for the aforementioned version and cannot be used for any other version.

Prerequisites

Before you start rolling back from v5.2, ensure that you have:

• ​No Process Flows or Templates/Automations in queued or running state.
• Deactivated all the dedicated deployments (if any).
• Updated the license by following the steps given below:
  1. Navigate to the /shared/license directory where the existing license.jar file is located.
  2. Rename the existing license file to license_old2.jar.
  3. Rename the old license file (Renamed as license_old.jar while upgrading) to license.jar.
• Scaled down the following microservices deployment:
  • api-publisher-gateway
  • event
  • listener
  • runtime
• Scaled down Redis StatefulSet, and then deleted Redis PVCs.

Steps to roll back from Adeptia Automate v5.2

Follow the steps below to roll back from v5.2.

1. If you have set the provisioningMode to static in your existing environment (v5.2):

   1. Clean up the existing RabbitMQ installation before rolling back:
      1. Scale down the RabbitMQ StatefulSet.
      2. Delete RabbitMQ PVCs.
      3. Delete RabbitMQ PVs.
      4. Recreate RabbitMQ PVs.
   2. Create three Redis PVs. (This step is required only when your target environment had Redis deployed in it.)​

2. Locate and open the values.yaml file that was used for the target rollback version.

3. In the databaseMigrationsection of the values.yaml file, do the following:

   1. Set the existing tag for the Database migration job to 5.2. ****
   2. Update the DB_UPDATE_MODE property to rollback.

4. Ensure that the value for the variables are set as mentioned in the table below:

   Variable	Section in values.yaml	Value
   EXECUTE_STATIC_JOB	global > static	true
   EXECUTE_MIGRATION_JOB	global > migration	true
   EXECUTE_CLEANUP_JOB	global > cleanup	true
   DELETE_RABBITMQ_STATEFULSET	global > cleanup	true
   DELETE_RABBITMQ_PVC	global > cleanup	true
   DELETE_RABBITMQ_CLUSTER	global > cleanup	true
   DELETE_RABBITMQ_CONFIG_SECRET	global > cleanup	true

5. Delete the existing RabbitMQ Cluster by running the following command:

Code

kubectl delete rabbitmqcluster <Name of the RabbitMQ Cluster> -n <Application Namespace>

6. Uninstall the existing RabbitMQ Operator:

Code

helm uninstall <Operator release name> -n <Operator Namespace>

7. If you want to rollback the application with HA mode of RabbitMQ, install the RabbitMQ Operator supported in the target environment (v5.1, v4.7.1, v4.7, v4.6), and then do the following:

   1. Open the values.yaml file.
   2. Navigate to rabbitmq section.
   3. Set the RabbitMQ_HA_mode to true.
   4. Set the replicaCount to 3.

These settings ensure that RabbitMQis deployed withthree replicas in HA mode when the application is deployed. 8. Run the following command to rollback:

Code

helm upgrade -i <Release Name> <Repo Name>/adeptia-connect --version <Target rollback version, for example, 5.1.0> -f <Path of the values.yaml> -n <Namespace>

Post rollback steps

After rolling back the application, you need to perform the following post-rollback steps:

1. Delete the AdeptiaAIModel file by following the steps below:

   1. Scale down the AIMap microservice deployment.
   2. Navigate to the shared/AIMap directory to locate the AdeptiaAIModel file.
   3. Delete the AdeptiaAIModel file.
   4. Scale up the AIMap microservice deployment.​​

2. Scale up the microservices deployments that you scaled down before the rollback.

3. Restore the cacerts that you stored as backup before upgrading to v5.2 and restart all the microservices.

4. Activate the dedicated deployments that you had deactivated before the rollback.