Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 10. Managing upgrades

This section provides step-by-step instructions to upgrade the OpenShift Serverless Logic Operator from version 1.34.0 to 1.35.0. The upgrade process involves preparing the existing workflows and services, updating the Operator, and restoring the workflows after the upgrade.

Note

Different workflow profiles require different upgrade steps. Carefully follow the instructions for each profile.

10.1.1. Preparing for the upgrade
Copia collegamento

Before starting the upgrade process, you need to prepare your OpenShift Serverless Logic environment. This section outlines the necessary steps to ensure a upgrade from version 1.34.0 to 1.35.0.

The preparation process includes:

  • Deleting or scaling workflows based on their profiles.
  • Backing up all necessary databases and resources.
  • Ensuring you have a record of all custom configurations.
  • Running required database migration scripts for workflows using persistence.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).

10.1.1.1. Deleting workflows with dev profile
Copia collegamento

Before upgrading the Operator, you must delete workflows running with the dev profile and redeploy them after the upgrade is completed.

Procedure

  1. Ensure you have a backup of all necessary Kubernetes resources, including SonataFlow custom resource definitions (CRDs), ConfigMaps, or any other related custom configurations.

  2. Delete the workflow by executing the following command: 

    $ oc delete -f <my-workflow.yaml> -n <target_namespace>

10.1.1.2. Deleting and migrating workflows with the preview profile
Copia collegamento

Before upgrading the Operator, you must delete workflows running with the Preview profile, and migrate any data that is persisted. When the upgrade is completed, you must redeploy the workflows.

Procedure

  1. If you are using persistence, back up the workflow database and ensure the backup includes both database objects and table data.
  2. Ensure you have a backup of all necessary Kubernetes resources, including SonataFlow CRDs, ConfigMaps, or any other related custom configurations.

  3. Delete the workflow by executing the following command: 

    $ oc delete -f <my-workflow.yaml> -n <target_namespace>

  4. If you are using persistence, you must execute the following database migration script: 

    ALTER TABLE flyway_schema_history
    RENAME CONSTRAINT flyway_schema_history_pk TO kie_flyway_history_runtime_persistence_pk;

ALTER INDEX flyway_schema_history_s_idx
  RENAME TO kie_flyway_history_runtime_persistence_s_idx;

ALTER TABLE flyway_schema_history RENAME TO kie_flyway_history_runtime_persistence;

10.1.1.3. Scaling down workflows with the gitops profile
Copia collegamento

Before upgrading the Operator, you must scale down workflows running with the gitops profile, and scale them up again after the upgrade is completed.

Procedure

  1. Modify the my-workflow.yaml CRD and scale down each workflow to zero before upgrading as shown in the following example: 

    spec:
  podTemplate:
    replicas: 0

  2. Apply the updated CRD by running the following command: 

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>

  3. (Optional) Scale the workflow to 0 by running the following command: 

    $ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'

10.1.1.4. Backing up the Data Index database
Copia collegamento

You must back up the Data Index database before upgrading to prevent data loss.

Procedure

  • Take a full backup of the Data Index database, ensuring:

    • The backup includes all database objects and not just table data.
    • The backup is stored in a secure location.

10.1.1.5. Backing up the Jobs Service database
Copia collegamento

You must back up the Jobs Service database before upgrading to maintain job scheduling data.

Procedure

  • Take a full backup of the Jobs Service database, ensuring:

    • The backup includes all database objects and not just table data.
    • The backup is stored in a secure location.

10.1.2. Upgrading the OpenShift Serverless Logic Operator
Copia collegamento

To transition from OpenShift Serverless Logic Operator (OSL) version 1.34.0 to 1.35.0, you must upgrade the OSL using the Red Hat OpenShift Serverless web console. This upgrade ensures compatibility with newer features and proper functioning of your workflows.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).

Procedure

  1. In the web console, navigate to the Operators OperatorHub Installed Operator page.
  2. Select the openshift-serverless-logic namespace from the Installed Namespace.
  3. In the list of installed operators, find and click the OpenShift Serverless Logic Operator.
  4. In the Operator details page, click on the Subscription tab. Click Edit Subscription.
  5. In the Upgrade status, click the Upgrade available link.
  6. Click the Preview install plan and Approve to start the update.

  7. To monitor the upgrade process, run the following command: 

    $ oc get subscription logic-operator-rhel8 -n openshift-serverless-logic -o jsonpath='{.status.installedCSV}'

    Expected output

    $ logic-operator-rhel8.v1.35.0

Verification

  1. To verify the new Operator version is installed, run the following command: 

    $ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic

    Expected output

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
logic-operator-rhel8.v1.35.0   OpenShift Serverless Logic Operator   1.35.0    logic-operator-rhel8.v1.34.0   Succeeded

10.1.3. Finalizing the upgrade
Copia collegamento

After upgrading the OpenShift Serverless Logic Operator to version 1.35.0, you must finalize the upgrade process by restoring or scaling workflows and cleaning up old services. This ensures that your system runs cleanly on the new version and that all dependent components are configured correctly.

Follow the appropriate steps below based on the profile of your workflows and services.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).

10.1.3.1. Finalizing the Data Index upgrade
Copia collegamento

After the Operator upgrade, a new ReplicaSet is automatically created for Data Index 1.35.0. You must delete the old one manually.

Procedure

  1. Verify the new ReplicaSet exists by listing all ReplicaSets by running the following command: 

    $ oc get replicasets -n <target_namespace> -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].image

  2. Identify the old Data Index ReplicaSet (with version 1.34.0) and delete it: 

    $ oc delete replicaset <old_replicaset_name> -n <target_namespace>

10.1.3.2. Finalizing the Job Service upgrade
Copia collegamento

You must manually clean up the Jobs Service components from the older version to trigger deployment of version 1.35.0 components.

Procedure

  1. Delete the old Jobs Service deployment by running the following command: 

    $ oc delete deployment <jobs-service-deployment-name> -n <target_namespace>

    This will trigger automatic cleanup of the older Pods and ReplicaSets and initiate a fresh deployment using version 1.35.0.

10.1.3.3. Redeploying workflows with the dev profile
Copia collegamento

After the upgrade, you must redeploy workflows that use the dev profile and any associated Kubernetes resources.

Procedure

  1. Ensure all required resources are restored, including SonataFlow CRDs, ConfigMaps, or any other related custom configurations.

  2. Redeploy the workflow by running the following command: 

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>

10.1.3.4. Restoring workflows with the preview profile
Copia collegamento

Workflows with the preview profile require an additional configuration step before being redeployed.

Procedure

  1. If the workflow uses persistence, add the following property to the ConfigMap associated with the workflow: 

    apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: my-workflow
  name: my-workflow-props
data:
  application.properties: |
    kie.flyway.enabled=true
  2. Ensure all required resources are recreated, including SonataFlow CRDs, ConfigMaps, or any other related custom configurations.

  3. Redeploy the workflow by running the following command: 

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>

10.1.3.5. Scaling up workflows with the gitops profile
Copia collegamento

Workflows with the gitops profile that were previously scaled down must be scaled back up to continue operation.

Procedure

  1. Modify the my-workflow.yaml CRD and scale up each workflow to one before upgrading as shown in the following example: 

    spec:
  podTemplate:
    replicas: 1

  2. Apply the updated CRD by running the following command: 

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>

  3. (Optional) Scale the workflow back to 1 by running the following command: 

    $ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'

10.1.3.6. Verifying the upgrade
Copia collegamento

After restoring workflows and services, it is essential to verify that the upgrade was successful and that all components are functioning as expected.

Procedure

  1. Check if all workflows and services are running by entering the following command: 

    $ oc get pods -n <target_namespace>

    Ensure that all pods related to workflows, Data Index, and Jobs Service are in a Running or Completed state.

  2. Verify that the OpenShift Serverless Logic Operator is running correctly by entering the following command: 

    $ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic

    Expected output

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
logic-operator-rhel8.v1.35.0   OpenShift Serverless Logic Operator   1.35.0    logic-operator-rhel8.v1.34.0   Succeeded

  3. Check Operator logs for any errors by entering the following command: 

    $ oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logic

You can upgrade the OpenShift Serverless Logic Operator from version 1.35.0 to 1.36.0. The upgrade process involves preparing the existing workflows and services, updating the Operator, and restoring the workflows after the upgrade.

Note

Different workflow profiles require different upgrade steps. Follow the instructions for each profile carefully.

10.2.1. Preparing for the upgrade
Copia collegamento

Before starting the upgrade process, you need to prepare your OpenShift Serverless Logic environment to upgrade from version 1.35.0 to 1.36.0.

The preparation process is as follows:

  • Deleting or scaling workflows based on their profiles.
  • Backing up all necessary databases and resources.
  • Ensuring you have a record of all custom configurations.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).

10.2.1.1. Deleting workflows with the dev profile
Copia collegamento

Before upgrading the Operator, you must delete workflows running with the dev profile and redeploy them after the upgrade is complete.

Procedure

  1. Ensure you have a backup of all necessary Kubernetes resources, including SonataFlow custom resources (CRs), ConfigMap resources, or any other related custom configurations.

  2. Delete the workflow by executing the following command: 

    $ oc delete workflow <workflow_name> -n <target_namespace>

10.2.1.2. Deleting workflows with the preview profile
Copia collegamento

Before upgrading the Operator, you must delete workflows running with the preview profile. When the upgrade is complete, you must redeploy the workflows.

Procedure

  1. If you are using persistence, back up the workflow database and ensure the backup includes both database objects and table data.
  2. Ensure you have a backup of all necessary Kubernetes resources, including SonataFlow custom resources (CRs), ConfigMap resources, or any other related custom configurations.

  3. Delete the workflow by executing the following command: 

    $ oc delete workflow <workflow_name> -n <target_namespace>

10.2.1.3. Scaling down workflows with the gitops profile
Copia collegamento

Before upgrading the Operator, you must scale down workflows running with the gitops profile, and scale them up again after the upgrade is complete.

Procedure

  1. Modify the my-workflow.yaml custom resources (CR) and scale down each workflow to 0 before upgrading as shown in the following example: 

    spec:
  podTemplate:
    replicas: 0
  # ...

  2. Apply the updated my-workflow.yaml CR by running the following command: 

    $ oc apply -f my-workflow.yaml -n <target_namespace>

  3. Optional: Scale the workflow to 0 by running the following command: 

    $ oc patch workflow <workflow_name> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'

10.2.1.4. Backing up the Data Index database
Copia collegamento

You must back up the Data Index database before upgrading to prevent data loss.

Procedure

  • Take a full backup of the Data Index database, ensuring:

    • The backup includes all database objects and not just table data.
    • The backup is stored in a secure location.

10.2.1.5. Backing up the Jobs Service database
Copia collegamento

You must back up the Jobs Service database before upgrading to maintain job scheduling data.

Procedure

  • Take a full backup of the Jobs Service database, ensuring:

    • The backup includes all database objects and not just table data.
    • The backup is stored in a secure location.

10.2.2. Upgrading the OpenShift Serverless Logic Operator to 1.36.0
Copia collegamento

You can upgrade the OpenShift Serverless Logic Operator from version 1.35.0 to 1.36.0 by performing the following steps.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).
  • You have version 1.35.0 of OpenShift Serverless Logic Operator installed.

Procedure

  1. Patch the ClusterServiceVersion (CSV) for the 1.35.0 OpenShift Serverless Logic Operator to update the deployment labels by running the following command: 

    $ oc patch csv logic-operator-rhel8.v1.35.0 \
  -n openshift-serverless-logic \
  --type=json \
  -p='[
    {
      "op": "replace",
      "path": "/spec/install/spec/deployments/0/spec/selector/matchLabels",
      "value": {
        "app.kubernetes.io/name": "sonataflow-operator"
      }
    },
    {
      "op": "replace",
      "path": "/spec/install/spec/deployments/0/label",
      "value": {
        "app.kubernetes.io/name": "sonataflow-operator"
      }
    },
    {
      "op": "replace",
      "path": "/spec/install/spec/deployments/0/spec/template/metadata/labels",
      "value": {
        "app.kubernetes.io/name": "sonataflow-operator"
      }
    }
  ]'

  2. Delete the current Operator deployment by running the following command: 

    $ oc delete deployment logic-operator-rhel8-controller-manager -n openshift-serverless-logic
  3. In the web console, navigate to the Operators OperatorHub Installed Operators page.
  4. In the list of installed Operators, find and click the Operator named OpenShift Serverless Logic Operator.
  5. Initiate the OpenShift Serverless Logic Operator upgrade to version 1.36.0.

Verification

  • After applying the upgrade, verify that the Operator is running and in the Succeeded phase, by running the following command: 

    $ oc get clusterserviceversion logic-operator-rhel8.v1.36.0

    Example output

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
logic-operator-rhel8.v1.36.0   OpenShift Serverless Logic Operator   1.36.0    logic-operator-rhel8.v1.35.0   Succeeded

10.2.3. Finalizing the upgrade
Copia collegamento

After upgrading the OpenShift Serverless Logic Operator to version 1.36.0, you must finalize the upgrade process by restoring or scaling workflows and cleaning up old services. This ensures that your system runs cleanly on the new version and that all dependent components are configured correctly.

Follow the appropriate steps below based on the profile of your workflows and services.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have access to the OpenShift Management Console for Operator upgrades.
  • You have installed the OpenShift CLI (oc).

10.2.3.1. Finalizing the Data Index upgrade
Copia collegamento

After the Operator upgrade, if your deployment is configured to use a Knative Eventing Kafka Broker, you must delete the old data-index-process-definition trigger that was created in the OpenShift Serverless Logic 1.35.0 version. Optionally, you can delete the old ReplicaSet resource as well.

Procedure

  1. List all the triggers by running the following command: 

    $ oc get triggers -n <target_namespace>

    Example output

    NAME                                                              BROKER              SUBSCRIBER_URI
data-index-jobs-a25c8405-f740-47d2-a9a5-f80ccaec2955              example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/jobs
data-index-process-definition-473e1ddbb3ca1d62768187eb80de99bca   example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/definitions
data-index-process-error-a25c8405-f740-47d2-a9a5-f80ccaec2955     example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/processes
data-index-process-instance-mul07f593476e8c14353a337590e0bfd5ae   example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/processes
data-index-process-node-a25c8405-f740-47d2-a9a5-f80ccaec2955      example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/processes
data-index-process-state-a25c8405-f740-47d2-a9a5-f80ccaec2955     example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/processes
data-index-process-variable-487e9a6777fff650e60097c9e17111aea25   example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/processes

jobs-service-create-job-a25c8405-f740-47d2-a9a5-f80ccaec2955      example-broker      http://sonataflow-platform-jobs-service.<target_namespace>.svc.cluster.local/v2/jobs/events
jobs-service-delete-job-a25c8405-f740-47d2-a9a5-f80ccaec2955      example-broker      http://sonataflow-platform-jobs-service.<target_namespace>.svc.cluster.local/v2/jobs/events

  2. Based on the generated example output, delete the old data-index-process-definition trigger by running the following command: 

    $ oc delete trigger data-index-process-definition-473e1ddbb3ca1d62768187eb80de99bca -n <target_namespace>

    After deletion, a new trigger compatible with OpenShift Serverless Logic 1.36.0 is automatically created.

  3. Optional: Identify the old ReplicaSet resource by running the following command: 

    $ oc get replicasets -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].image -n <target_namespace>

    Example output

    Name                                                Image
sonataflow-platform-data-index-service-1111111111   registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.35.0

sonataflow-platform-data-index-service-2222222222   registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.36.0

  4. Optional: Delete your old ReplicaSet resource by running the following command: 

    $ oc delete replicaset <old_replicaset_name> -n <target_namespace>

    Example command based on the example output

    $ oc delete replicaset sonataflow-platform-data-index-service-1111111111 -n <target_namespace>

10.2.3.2. Finalizing the Job Service upgrade
Copia collegamento

After the OpenShift Serverless Operator is upgraded to version 1.36.0 you can optionally delete the old ReplicaSet resource.

Procedure

  1. Identify the old ReplicaSet resource by running the following command: 

    $ oc get replicasets -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].image -n <target_namespace>

    Example output

    Name                                                Image
sonataflow-platform-jobs-service-1111111111         registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.35.0
sonataflow-platform-jobs-service-2222222222         registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.36.0

  2. Delete your old ReplicaSet resource by running the following command: 

    $ oc delete replicaset <old_replicaset_name> -n <target_namespace>

    Example command based on the example output

    $ oc delete replicaset sonataflow-platform-jobs-service-1111111111 -n <target_namespace>

10.2.3.3. Redeploying workflows with the dev profile
Copia collegamento

After the upgrade, you must redeploy workflows that use the dev profile and any associated Kubernetes resources.

Procedure

  1. Ensure that all required Kubernetes resources, including the ConfigMap with the application.properties field, are restored before redeploying the workflow.

  2. Redeploy the workflow by running the following command: 

    $ oc apply -f <workflow_name> -n <target_namespace>

10.2.3.4. Restoring workflows with the preview profile
Copia collegamento

After the upgrade, you must redeploy workflows that use the preview profile and any associated Kubernetes resources.

Procedure

  1. Ensure that all required Kubernetes resources, including the ConfigMap with the application.properties field, are restored before redeploying the workflow.

  2. Redeploy the workflow by running the following command: 

    $ oc apply -f <workflow_name> -n <target_namespace>

10.2.3.5. Scaling up workflows with the gitops profile
Copia collegamento

To continue operation, you must scale up workflows that you previously scaled down with the gitops profile.

Procedure

  1. Modify the my-workflow.yaml custom resources (CR) and scale up each workflow to 1 as shown in the following example: 

    spec:
  podTemplate:
    replicas: 1
  # ...

  2. Apply the updated CR by running the following command: 

    $ oc apply -f my-workflow.yaml -n <target_namespace>

  3. Optional: Scale the workflow back to 1 by running the following command: 

    $ oc patch workflow <workflow_name> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'

10.2.4. Verifying the 1.36.0 upgrade
Copia collegamento

After restoring workflows and services, verify that the upgrade was successful and all components are functioning as expected.

Procedure

  1. Check if all workflows and services are running by entering the following command: 

    $ oc get pods -n <target_namespace>

    Ensure that all pods related to workflows, Data Index, and Jobs Service are in a Running or Completed state.

  2. Verify that the OpenShift Serverless Logic Operator is running correctly by entering the following command: 

    $ oc get clusterserviceversion logic-operator-rhel8.v1.36.0 -n openshift-serverless-logic

    Example output

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
logic-operator-rhel8.v1.36.0   OpenShift Serverless Logic Operator   1.36.0    logic-operator-rhel8.v1.35.0   Succeeded

  3. Check Operator logs for any errors by entering the following command: 

    $ oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logic
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima