Skip to content

Commit e6af34e

Browse files
ricardozaniniricardozanini
authored
Merge pull request #130 from wmedvede/SRVLOGIC-773
SRVLOGIC-773: Operator, DI, JS and Workflows migration from OSL 1.37.0 to OSL 1.37.1
2 parents e3c7d9e + dc1f261 commit e6af34e

7 files changed

Lines changed: 393 additions & 0 deletions

File tree

‎modules/ROOT/nav.adoc‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -93,6 +93,7 @@
9393
****** xref:serverless-logic:cloud/operator/upgrade-serverless-operator/upgrade_1_34_0_to_1_35_0.adoc[OSL 1.34.0 to 1.35.0]
9494
****** xref:serverless-logic:cloud/operator/upgrade-serverless-operator/upgrade_1_35_0_to_1_36_0.adoc[OSL 1.35.0 to 1.36.0]
9595
****** xref:serverless-logic:cloud/operator/upgrade-serverless-operator/upgrade_1_36_0_to_1_37_0.adoc[OSL 1.36.0 to 1.37.0]
96+
****** xref:serverless-logic:cloud/operator/upgrade-serverless-operator/upgrade_1_37_0_to_1_37_1.adoc[OSL 1.37.0 to 1.37.1]
9697
***** xref:serverless-logic:cloud/operator/global-configuration.adoc[Admin Configuration]
9798
***** xref:serverless-logic:cloud/operator/developing-workflows.adoc[Development Mode]
9899
***** xref:serverless-logic:cloud/operator/referencing-resource-files.adoc[Referencing Workflow Resources]

‎modules/serverless-logic/pages/_common-content/cloud/operator/upgrade-serverless-operator/regular_dev_workflow_upgrade_procedure.adoc‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
// Regular procedure for dev profile workflows migration.
2+
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
3+
// current_operator_version, next_operator_version
4+
:page-partial:
5+
6+
Every workflow with the `dev` profile must be deleted before applying the Operator upgrade to the version `{next_operator_version}`, and then redeployed after the upgrade is completed.
7+
8+
For every workflow `my-workflow` with the `dev` profile you must:
9+
10+
*Pre-operator upgrade steps:*
11+
12+
. Ensure that you have a copy of the corresponding `SonataFlow` CR, as well as any other Kubernetes resources created for that workflow. For example, if you are using custom property configurations, you will need a copy of the user-provided `ConfigMap` with the `application.properties` file.
13+
14+
. Delete the workflow by using the following command:
15+
+
16+
[source,terminal]
17+
----
18+
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
19+
----
20+
21+
*Post-operator upgrade steps:*
22+
23+
[start=3]
24+
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.
25+
26+
. Redeploy the workflow by using the following command:
27+
+
28+
[source,terminal]
29+
----
30+
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
31+
----

‎modules/serverless-logic/pages/_common-content/cloud/operator/upgrade-serverless-operator/regular_gitops_worklow_upgrade_procedure_with_image_build.adoc‎

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
// Regular procedure for gitops workflows migration that requires (or the user optionally wants) a rebuild of the workflow image.
2+
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
3+
// current_operator_version, next_operator_version and next_swf_builder_image.
4+
:page-partial:
5+
6+
*Pre-operator upgrade steps:*
7+
8+
. Rebuild the workflow image using the new {product_name} `{next_operator_version}` workflow builder `{next_swf_builder_image}` and reconfigure your workflow, considering the following:
9+
10+
+
11+
By default, the {product_name} generates a workflow `Deployment` with `imagePullPolicy: IfNotPresent`.
12+
This means that if an already deployed workflow is redeployed using the same image name, the previously downloaded image will be reused, even if the image was rebuilt.
13+
14+
+
15+
[IMPORTANT]
16+
====
17+
In all cases, you are not generating a new workflow version, but a new image build. Therefore, you must not change the workflow definition or any related assets, including the name, version, and description.
18+
====
19+
20+
+
21+
To ensure that the new image is pulled, you can:
22+
+
23+
24+
25+
* Use a new image tag and configure the workflow to use it (recommended):
26+
+
27+
[source,yaml]
28+
----
29+
current image: quay.io/my-images/my-workflow:1.0
30+
new image: quay.io/my-images/my-workflow:1.0-1
31+
----
32+
+
33+
[source,yaml]
34+
----
35+
apiVersion: sonataflow.org/v1alpha08
36+
kind: SonataFlow
37+
metadata: # don't change
38+
name: my-workflow
39+
annotations:
40+
sonataflow.org/description: My Workflow
41+
sonataflow.org/version: '1.0'
42+
sonataflow.org/profile: gitops
43+
spec:
44+
podTemplate:
45+
container:
46+
# only change the image name/tag
47+
image: quay.io/my-images/my-workflow:1.0-1
48+
flow:
49+
# the workflow definition (don't change)
50+
----
51+
+
52+
* Preserve the image name, and configure the workflow with the `imagePullPolicy: Always`.
53+
+
54+
[source,yaml]
55+
----
56+
apiVersion: sonataflow.org/v1alpha08
57+
kind: SonataFlow
58+
metadata: # don't change
59+
name: my-workflow
60+
annotations:
61+
sonataflow.org/description: My Workflow
62+
sonataflow.org/version: '1.0'
63+
sonataflow.org/profile: gitops
64+
spec:
65+
podTemplate:
66+
container:
67+
image: quay.io/my-images/my-workflow:1.0
68+
# only change the imagePullStrategy
69+
imagePullPolicy: Always
70+
flow:
71+
# the workflow definition (don't change).
72+
----
73+
+
74+
75+
. If the workflow is configured to use persistence, you must back up the workflow database.
76+
Ensure that your database backup includes all database objects, not just the table's information.
77+
78+
+
79+
. Ensure that you have a copy of the corresponding `SonataFlow` CR, as well as any other Kubernetes resources created for that workflow.
80+
For example, if you are using custom property configurations, you will need a copy of the user-provided `ConfigMap` with the `application.properties` file.
81+
82+
+
83+
. Delete the workflow by using the following command:
84+
85+
+
86+
[source,terminal]
87+
----
88+
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
89+
----
90+
91+
[#workflows_gitops_profile_image_rebuild_post_upgrade]
92+
*Post-operator upgrade steps:*
93+
94+
[start=5]
95+
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.
96+
97+
+
98+
. Redeploy the reconfigured workflow using the following command:
99+
+
100+
[source,terminal]
101+
----
102+
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
103+
----

‎modules/serverless-logic/pages/_common-content/cloud/operator/upgrade-serverless-operator/regular_jobs_service_upgrade_procedure.adoc‎

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
// Regular Jobs service upgrade procedure.
2+
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
3+
// current_operator_version, next_operator_version
4+
:page-partial:
5+
6+
Every Job Service deployment must be upgraded with the following procedure:
7+
8+
*Pre-operator upgrade steps:*
9+
10+
. Back up the Job Service database, including all database objects, not just the table information.
11+
12+
. Scale the Job Service to zero
13+
+
14+
You can scale the Job Service to zero with the following command:
15+
16+
+
17+
[source, bash]
18+
----
19+
oc patch sonataflowplatform <my-sonataflow-platform> -n <target_namespace> \
20+
--type merge \
21+
-p '{"spec":{"services":{"jobService":{"podTemplate":{"replicas":0}}}}}'
22+
----
23+
24+
*Post-operator upgrade steps:*
25+
26+
[start=3]
27+
. Rescale the Job Service
28+
+
29+
After redeploying and rescaling all the workflows, you must rescale the Job Service to 1 with the following command:
30+
+
31+
[source, bash]
32+
----
33+
oc patch sonataflowplatform <my-sonataflow-platform> -n <target_namespace> \
34+
--type merge \
35+
-p '{"spec":{"services":{"jobService":{"podTemplate":{"replicas":1}}}}}'
36+
----

‎modules/serverless-logic/pages/_common-content/cloud/operator/upgrade-serverless-operator/regular_operator_upgrade_procedure.adoc‎

Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
// Regular operator upgrade procedure by executing the available installing plan for the next version.
2+
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
3+
// current_operator_version, next_operator_version
4+
:page-partial:
5+
6+
+
7+
. Execute the following command to query the available installation plan for the Operator upgrade to `{next_operator_version}`:
8+
+
9+
[source,bash]
10+
----
11+
oc get installplan -n openshift-serverless-logic
12+
----
13+
+
14+
You must get an output like this:
15+
+
16+
[source,terminal,subs="attributes"]
17+
----
18+
NAME CSV APPROVAL APPROVED
19+
install-YYYY logic-operator.v{next_operator_version} Manual false
20+
install-XXXX logic-operator.v{current_operator_version} Manual true
21+
----
22+
+
23+
Approve the installation plan corresponding to `logic-operator.v{next_operator_version}` with a command like this:
24+
+
25+
[source,bash,subs="attributes"]
26+
----
27+
oc patch installplan install-YYYY -n openshift-serverless-logic --type merge -p '{"spec":{"approved":true}}'
28+
----
29+
. Verify that the {operator_name} `{next_operator_version}` was updated correctly:
30+
+
31+
When the installation plan is executed, you can execute the following command to verify the upgrade was successful:
32+
+
33+
[source,bash]
34+
----
35+
oc get csv -n openshift-serverless-logic
36+
----
37+
+
38+
You must get an output like this:
39+
+
40+
[source,terminal,subs="attributes"]
41+
----
42+
NAME DISPLAY VERSION REPLACES PHASE
43+
logic-operator.v{next_operator_version} OpenShift Serverless Logic Operator {next_operator_version} logic-operator.v{current_operator_version} Succeeded
44+
----

‎modules/serverless-logic/pages/_common-content/cloud/operator/upgrade-serverless-operator/regular_preview_workflow_upgrade_procedure.adoc‎

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
// Regular procedure for preview profile workflows migration.
2+
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
3+
// current_operator_version, next_operator_version
4+
:page-partial:
5+
6+
Every workflow with the `preview` profile must be deleted before applying the Operator upgrade to the version `{next_operator_version}`, and then, redeployed after the upgrade is completed.
7+
8+
For every workflow `my-workflow` with the `preview` profile you must:
9+
10+
*Pre-operator upgrade steps:*
11+
12+
. If the workflow is configured to use persistence, you must back up the workflow database.
13+
Ensure that your database backup includes all database objects, not just the table's information.
14+
15+
. Ensure that you have a copy of the corresponding `SonataFlow` CR, as well as any other Kubernetes resources created for that workflow. For example, if you are using custom property configurations, you will need a copy of the user-provided `ConfigMap` with the `application.properties` file.
16+
17+
. Delete the workflow by using the following command:
18+
+
19+
[source,terminal]
20+
----
21+
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
22+
----
23+
24+
*Post-operator upgrade steps:*
25+
26+
[start=4]
27+
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.
28+
29+
+
30+
. Redeploy the workflow by using the following command:
31+
+
32+
[source,terminal]
33+
----
34+
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
35+
----

0 commit comments

Comments
 (0)