Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 8. Managing upgrades
8.1. Upgrading OpenShift Serverless Logic Operator from version 1.34.0 to 1.35.0 Copier lienLien copié sur presse-papiers!
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.
Different workflow profiles require different upgrade steps. Carefully follow the instructions for each profile.
8.1.1. Preparing for the upgrade Copier lienLien copié sur presse-papiers!
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-adminprivileges. - 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).
8.1.1.1. Deleting workflows with dev profile Copier lienLien copié sur presse-papiers!
Before upgrading the Operator, you must delete workflows running with the dev profile and redeploy them after the upgrade is completed.
Procedure
-
Ensure you have a backup of all necessary Kubernetes resources, including
SonataFlowcustom resource definitions (CRDs),ConfigMaps, or any other related custom configurations. Delete the workflow by executing the following command:
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
8.1.1.2. Deleting and migrating workflows with the preview profile Copier lienLien copié sur presse-papiers!
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
- If you are using persistence, back up the workflow database and ensure the backup includes both database objects and table data.
-
Ensure you have a backup of all necessary Kubernetes resources, including
SonataFlowCRDs,ConfigMaps, or any other related custom configurations. Delete the workflow by executing the following command:
$ oc delete -f <my-workflow.yaml> -n <target_namespace>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;
8.1.1.3. Scaling down workflows with the gitops profile Copier lienLien copié sur presse-papiers!
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
Modify the
my-workflow.yamlCRD and scale down each workflow tozerobefore upgrading as shown in the following example:spec: podTemplate: replicas: 0Apply the updated CRD by running the following command:
$ oc apply -f <my-workflow.yaml> -n <target_namespace>(Optional) Scale the workflow to
0by running the following command:$ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'
8.1.1.4. Backing up the Data Index database Copier lienLien copié sur presse-papiers!
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.
8.1.1.5. Backing up the Jobs Service database Copier lienLien copié sur presse-papiers!
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.
8.1.2. Upgrading the OpenShift Serverless Logic Operator Copier lienLien copié sur presse-papiers!
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-adminprivileges. - 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
-
In the web console, navigate to the Operators
OperatorHub Installed Operator page. -
Select the
openshift-serverless-logicnamespace from the Installed Namespace. - In the list of installed operators, find and click the OpenShift Serverless Logic Operator.
- In the Operator details page, click on the Subscription tab. Click Edit Subscription.
- In the Upgrade status, click the Upgrade available link.
- Click the Preview install plan and Approve to start the update.
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
To verify the new Operator version is installed, run the following command:
$ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logicExpected 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
8.1.3. Finalizing the upgrade Copier lienLien copié sur presse-papiers!
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-adminprivileges. - 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).
8.1.3.1. Finalizing the Data Index upgrade Copier lienLien copié sur presse-papiers!
After the Operator upgrade, a new ReplicaSet is automatically created for Data Index 1.35.0. You must delete the old one manually.
Procedure
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[*].imageIdentify the old Data Index ReplicaSet (with version 1.34.0) and delete it:
$ oc delete replicaset <old_replicaset_name> -n <target_namespace>
8.1.3.2. Finalizing the Job Service upgrade Copier lienLien copié sur presse-papiers!
You must manually clean up the Jobs Service components from the older version to trigger deployment of version 1.35.0 components.
Procedure
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.
8.1.3.3. Redeploying workflows with the dev profile Copier lienLien copié sur presse-papiers!
After the upgrade, you must redeploy workflows that use the dev profile and any associated Kubernetes resources.
Procedure
-
Ensure all required resources are restored, including
SonataFlowCRDs,ConfigMaps, or any other related custom configurations. Redeploy the workflow by running the following command:
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
8.1.3.4. Restoring workflows with the preview profile Copier lienLien copié sur presse-papiers!
Workflows with the preview profile require an additional configuration step before being redeployed.
Procedure
If the workflow uses persistence, add the following property to the
ConfigMapassociated with the workflow:apiVersion: v1 kind: ConfigMap metadata: labels: app: my-workflow name: my-workflow-props data: application.properties: | kie.flyway.enabled=true-
Ensure all required resources are recreated, including
SonataFlowCRDs,ConfigMaps, or any other related custom configurations. Redeploy the workflow by running the following command:
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
8.1.3.5. Scaling up workflows with the gitops profile Copier lienLien copié sur presse-papiers!
Workflows with the gitops profile that were previously scaled down must be scaled back up to continue operation.
Procedure
Modify the
my-workflow.yamlCRD and scale up each workflow toonebefore upgrading as shown in the following example:spec: podTemplate: replicas: 1Apply the updated CRD by running the following command:
$ oc apply -f <my-workflow.yaml> -n <target_namespace>(Optional) Scale the workflow back to
1by running the following command:$ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'
8.1.3.6. Verifying the upgrade Copier lienLien copié sur presse-papiers!
After restoring workflows and services, it is essential to verify that the upgrade was successful and that all components are functioning as expected.
Procedure
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
RunningorCompletedstate.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-logicExpected 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 SucceededCheck Operator logs for any errors by entering the following command:
$ oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logic