5 Rolling Back OCNADD

This chapter describes the OCNADD rollback procedure from a target release to a previously supported version. In the current release, centralized deployment is supported, and OCNADD microservices will follow the centralized deployment mode with the management group and the worker group separation concerning microservices functions.

The rollback will be supported for the following cases:

  • Upgrade was done from source releases to the target release in the Centralized deployment mode.

Note:

Changing mode from Centralized deployment mode to Non-Centralized deployment is not supported within the target release (25.1.201). See Supported Upgrade Paths section of this document.

Supported Rollback Paths

Table 5-1 Supported Rollback Paths

Source Release Target Release
25.1.201 25.1.200

Rollback Steps

These steps are common for all the rollback cases. To roll back to a previous version, follow the steps as mentioned:

Note:

  • (Optional) A timeout interval of 15 minutes can be set while performing an upgrade as only one POD of the OCNADD services is upgraded at a time.
  • Ensure the status for the target version in the helm history is not in failed or error state.

Rollback Usecase 2: Upgrade Was Done from Source Releases (Centralized) to Target Release in the Centralized Deployment Mode

Note:

This scenario is applicable for rollback from 25.1.201 Centralized Deployment Mode to 25.1.200 Centralized Deployment Mode.

To roll back to a previous working version in the target rollback release, follow these steps:

Rollback of Management Group:

  1. Check Revision of the Management Group Release to Rollback:
    helm history <ocandd-release-name> --namespace <ocndd-mgmt-namespace>

    Where,

    <ocandd-release-name> is the release name used for default worker group deployment.

    For example:
    helm history ocnadd --namespace ocnadd-deploy
    Sample Helm history output:
    
    REVISION   UPDATED                     STATUS        CHART                         APP VERSION       DESCRIPTION 
    1          Fri Feb 08 04:57:43 2024    superseded    ocnadd-0.0.0-25.1.200         25.1.200          Install complete 
    2          Fri Feb 08 05:07:43 2024    superseded    ocnadd-0.0.0-25.1.201         25.1.201          Upgrade complete 
  2. Rollback to Required Revision:
    helm rollback <ocandd-release-name> <REVISION> --namespace <ocndd-mgmt-namespace>

    Where,

    <REVISION> is the revision number obtained in the previous step to which the services need to be rolled back.

    For example:
    helm rollback ocnadd 2 --namespace ocnadd-deploy

Rollback of Worker Groups

  1. Check Revision for Rollback:
    helm history <ocandd-release-name> --namespace <ocnadd-workergroup-namespace>

    Where,

    <ocandd-release-name> is the release name used for default worker group deployment.

    For example:
    helm history ocnadd --namespace ocnadd-deploy
    Sample Helm history output:
    
    REVISION   UPDATED                     STATUS        CHART                         APP VERSION       DESCRIPTION 
    1          Fri Feb 08 04:57:43 2024    superseded    ocnadd-0.0.0-25.1.200         25.1.200          Install complete 
    2          Fri Feb 08 05:07:43 2024    deployed      ocnadd-0.0.0-25.1.201         25.1.201          Upgrade complete
  2. Rollback to Required Revision:
    helm rollback <ocandd-release-name> <REVISION> --namespace <ocndd-workergroup-namespace>

    Where,

    <REVISION> is the revision number obtained in the previous step to which the services need to be rolled back.

    For example:
    helm rollback ocnadd 2 --namespace ocnadd-deploy
  3. Rollback Adapter Services to the Previous Version. Run the below commands to rollback all Adapter/Correlation services to the previous version:
    1. Perform helm upgrade using the management group charts folder:
      1. If no correlation configurations are present:
        helm upgrade <management-release-name> -f ocnadd-custom-values-<mgmt-group>.yaml --namespace <ocnadd-namespace> <mgmt_helm_chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
        For example:
        helm upgrade ocnadd-mgmt -f ocnadd-custom-values-mgmt-group.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true 
      2. If correlation configurations are also present:
        helm upgrade <management-release-name> -f ocnadd-custom-values-<mgmt-group>.yaml --namespace <ocnadd-namespace> <mgmt_helm_chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true

        Note:

        If the correlation configuration was enabled for extended storage (from 24.2.0 onwards) then also use the flag "global.env.admin.OCNADD_STORAGE_ADAPTER_UPGRADE_ENABLE=true" in the above command.
        For example:
        helm upgrade ocnadd-mgmt -f ocnadd-custom-values-mgmt-group.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true

        Note:

        If the correlation configuration was enabled for extended storage (from 24.2.0 onwards), then also use the flag global.env.admin.OCNADD_STORAGE_ADAPTER_UPGRADE_ENABLE=true in the above command.
        helm upgrade ocnadd-mgmt -f ocnadd-custom-values-mgmt-group.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true,global.env.admin.OCNADD_STORAGE_ADAPTER_UPGRADE_ENABLE=true
      3. If ingress adapter configurations are also present:
        helm upgrade <management-release-name> -f ocnadd-custom-values-<mgmt-group>.yaml --namespace <ocnadd-namespace> <mgmt_helm_chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true,global.env.admin.OCNADD_INGRESS_ADAPTER_UPGRADE_ENABLE=true
        For example:
        helm upgrade ocnadd-mgmt -f ocnadd-custom-values-mgmt-group.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true,global.env.admin.OCNADD_INGRESS_ADAPTER_UPGRADE_ENABLE=true
  4. Check the status of the upgrade, and monitor the pods to come back to the RUNNING state.

Note:

  • If the rollback is unsuccessful, see troubleshooting steps outlined in the Oracle Communications Network Analytics Data Director Troubleshooting Guide.
  • On rollback completion, if the export, correlation, aggregation, ingress-adapter and/or consumer adapter services may not receive the configuration notification in timely manner and start processing data, then see the section "Invalid Subscription entry in the subscription table" in the Oracle Communication Network Analytics Troubleshooting Guide.
  • If the rollback is successful and intraTLS is disabled, then create the certificates of all the OCNADD services. For required certificates, see rollbacked release Oracle Communication Network Analytics Security Guide.