This article covers upgrading an on-premises Cequence Platform installation from release 9.2.x to release 9.3.0, and rolling back if needed. Release 9.3.0 upgrades the bundled Strimzi Kafka Operator from release 0.51.0 to 1.2.0, moves the underlying Kafka version from 4.2.0 to 4.3.1, and migrates Kafka custom resource definitions to v1. Read this article fully before you begin.

SaaS-hosted environments are upgraded by Cequence directly. This article is for on-premises installations using Helm.

Before you upgrade to release 9.3.0

Complete the following before starting the upgrade.

Export your current configuration. Keep this export so you can restore your configuration if you need to roll back.

Upgrading to release 9.3.0

Complete the steps in order. Each step depends on the one before it.

1. Export all current configuration, when you have not already done so as part of the prerequisites above.

2. Migrate your existing Strimzi custom resource definitions (CRDs) to the v1 schema.

   Add the following to your Helm values override file. Enable this flag only long enough to generate the migration job in the next step, then set it back to false so the job does not run again on a future upgrade.

   strimziApiConversion:
     enabled: true

   Generate the migration job manifest.

   helm template cequence cequence/cequence-asp --version 9.3.0 -f override.yaml -s templates/kafka/strimzi-v1-api-conversion.yaml > migrate.job

   Set strimziApiConversion.enabled back to false in your override file, then apply the generated manifest to start the CRD migration.

   kubectl apply -f migrate.job -n <namespace> --context <kubernetes context>

3. Download the Strimzi Kafka Operator Helm chart for release 1.2.0 and apply the custom resource definitions (CRDs) it provides.

   kubectl apply -f strimzi-operator-helm-1.2.0/strimzi-kafka-operator/crds/ --context <target context>

4. Upgrade the Strimzi operator to release 1.2.0.

   helm upgrade --install strimzi strimzi/strimzi-kafka-operator --version 1.2.0 -n <namespace> --values strimzi-kafka-operator-values.yaml

5. Run the Helm upgrade to release 9.3.0.

   The upgrade recreates pods across the platform as it proceeds. Monitor the rollout and verify that each component reaches a healthy state before considering the upgrade complete.

After the upgrade completes, the platform is running release 9.3.0 with Kafka on Strimzi 1.2.0. Continue to the verification steps below.

Verifying the upgrade

Verify the following after the upgrade completes and before you consider it finished.

• Verify that all pods are running properly.
• Verify that the platform version shows release 9.3.0.
• Verify that the Strimzi custom resource definitions show v1.
• Check system logs across the platform for errors or warnings.

Detection Dashboard behavior also changes after this upgrade. When a filter applied on the Detected Transactions page doesn't exist on Detection Dashboard, navigating to Detection Dashboard no longer shows a blank screen with no visible filter. Instead, the platform skips the incompatible filter and Detection Dashboard shows data normally. Your filter selection is still saved, so returning to Detected Transactions shows it again. Selecting View Transactions from pivot details sets your saved filters to match the pivot you selected.

Once verification passes, monitor system performance for a couple of hours before considering the upgrade complete. Watch for error logs or unusual behavior during this window.

Rolling back to release 9.2.2 or later

If you need to roll back, roll back to release 9.2.2 or a later 9.2.x release, regardless of which 9.2.x release you upgraded from.

1. Reapply the Strimzi Kafka Operator release 0.51.0 custom resource definitions (CRDs).

   kubectl apply -f strimzi-operator-helm-0.51.0/strimzi-kafka-operator/crds/ --context <target context>

2. Downgrade the Strimzi operator to release 0.51.0.

   helm upgrade --install strimzi strimzi/strimzi-kafka-operator --version 0.51.0 -n <namespace> --values strimzi-kafka-operator-values.yaml

3. Run the Helm upgrade specifying release 9.2.2 or later.

   Monitor the downgrade as components revert. If airflow-api-server enters a crash loop during this step, delete the pod. It recovers on restart.

4. Import the configuration you exported before the upgrade.

Verifying the rollback

• Verify that all pods are running properly.
• Verify that the platform version has downgraded correctly to release 9.2.2 or later.
• Check system logs for errors or warnings.
• Verify that each configured data export is receiving data.