Skip to content

SRVLOGIC-773: Operator, DI, JS and Workflows migration from OSL 1.37.0 to OSL 1.37.1 #130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wmedvede wants to merge 1 commit into
base: master
Choose a base branch
from
Open

SRVLOGIC-773: Operator, DI, JS and Workflows migration from OSL 1.37.0 to OSL 1.37.1 #130

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions modules/ROOT/nav.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,7 @@
****** 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]
****** 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]
****** 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]
****** 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]
***** xref:serverless-logic:cloud/operator/global-configuration.adoc[Admin Configuration]
***** xref:serverless-logic:cloud/operator/developing-workflows.adoc[Development Mode]
***** xref:serverless-logic:cloud/operator/referencing-resource-files.adoc[Referencing Workflow Resources]
Expand Down
31 changes: 31 additions & 0 deletions ...perator/upgrade-serverless-operator/regular_dev_workflow_upgrade_procedure.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
// Regular procedure for dev profile workflows migration.
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
// current_operator_version, next_operator_version
:page-partial:

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.

For every workflow `my-workflow` with the `dev` profile you must:

*Pre-operator upgrade steps:*

. 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.

. Delete the workflow by using the following command:
+
[source,terminal]
----
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
----

*Post-operator upgrade steps:*

[start=3]
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.

. Redeploy the workflow by using the following command:
+
[source,terminal]
----
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
----
103 changes: 103 additions & 0 deletions ...verless-operator/regular_gitops_worklow_upgrade_procedure_with_image_build.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
// Regular procedure for gitops workflows migration that requires (or the user optionally wants) a rebuild of the workflow image.
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
// current_operator_version, next_operator_version and next_swf_builder_image.
:page-partial:

*Pre-operator upgrade steps:*

. 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:

+
By default, the {product_name} generates a workflow `Deployment` with `imagePullPolicy: IfNotPresent`.
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.

+
[IMPORTANT]
====
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.
====

+
To ensure that the new image is pulled, you can:
+


* Use a new image tag and configure the workflow to use it (recommended):
+
[source,yaml]
----
current image: quay.io/my-images/my-workflow:1.0
new image: quay.io/my-images/my-workflow:1.0-1
----
+
[source,yaml]
----
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata: # don't change
name: my-workflow
annotations:
sonataflow.org/description: My Workflow
sonataflow.org/version: '1.0'
sonataflow.org/profile: gitops
spec:
podTemplate:
container:
# only change the image name/tag
image: quay.io/my-images/my-workflow:1.0-1
flow:
# the workflow definition (don't change)
----
+
* Preserve the image name, and configure the workflow with the `imagePullPolicy: Always`.
+
[source,yaml]
----
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata: # don't change
name: my-workflow
annotations:
sonataflow.org/description: My Workflow
sonataflow.org/version: '1.0'
sonataflow.org/profile: gitops
spec:
podTemplate:
container:
image: quay.io/my-images/my-workflow:1.0
# only change the imagePullStrategy
imagePullPolicy: Always
flow:
# the workflow definition (don't change).
----
+

. If the workflow is configured to use persistence, you must back up the workflow database.
Ensure that your database backup includes all database objects, not just the table's information.

+
. 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.

+
. Delete the workflow by using the following command:

+
[source,terminal]
----
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
----

[#workflows_gitops_profile_image_rebuild_post_upgrade]
*Post-operator upgrade steps:*

[start=5]
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.

+
. Redeploy the reconfigured workflow using the following command:
+
[source,terminal]
----
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
----
36 changes: 36 additions & 0 deletions ...perator/upgrade-serverless-operator/regular_jobs_service_upgrade_procedure.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
// Regular Jobs service upgrade procedure.
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
// current_operator_version, next_operator_version
:page-partial:

Every Job Service deployment must be upgraded with the following procedure:

*Pre-operator upgrade steps:*

. Back up the Job Service database, including all database objects, not just the table information.

. Scale the Job Service to zero
+
You can scale the Job Service to zero with the following command:

+
[source, bash]
----
oc patch sonataflowplatform <my-sonataflow-platform> -n <target_namespace> \
--type merge \
-p '{"spec":{"services":{"jobService":{"podTemplate":{"replicas":0}}}}}'
----

*Post-operator upgrade steps:*

[start=3]
. Rescale the Job Service
+
After redeploying and rescaling all the workflows, you must rescale the Job Service to 1 with the following command:
+
[source, bash]
----
oc patch sonataflowplatform <my-sonataflow-platform> -n <target_namespace> \
--type merge \
-p '{"spec":{"services":{"jobService":{"podTemplate":{"replicas":1}}}}}'
----
44 changes: 44 additions & 0 deletions ...ud/operator/upgrade-serverless-operator/regular_operator_upgrade_procedure.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
// Regular operator upgrade procedure by executing the available installing plan for the next version.
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
// current_operator_version, next_operator_version
:page-partial:

+
. Execute the following command to query the available installation plan for the Operator upgrade to `{next_operator_version}`:
+
[source,bash]
----
oc get installplan -n openshift-serverless-logic
----
+
You must get an output like this:
+
[source,terminal,subs="attributes"]
----
NAME CSV APPROVAL APPROVED
install-YYYY logic-operator.v{next_operator_version} Manual false
install-XXXX logic-operator.v{current_operator_version} Manual true
----
+
Approve the installation plan corresponding to `logic-operator.v{next_operator_version}` with a command like this:
+
[source,bash,subs="attributes"]
----
oc patch installplan install-YYYY -n openshift-serverless-logic --type merge -p '{"spec":{"approved":true}}'
----
. Verify that the {operator_name} `{next_operator_version}` was updated correctly:
+
When the installation plan is executed, you can execute the following command to verify the upgrade was successful:
+
[source,bash]
----
oc get csv -n openshift-serverless-logic
----
+
You must get an output like this:
+
[source,terminal,subs="attributes"]
----
NAME DISPLAY VERSION REPLACES PHASE
logic-operator.v{next_operator_version} OpenShift Serverless Logic Operator {next_operator_version} logic-operator.v{current_operator_version} Succeeded
----
35 changes: 35 additions & 0 deletions ...tor/upgrade-serverless-operator/regular_preview_workflow_upgrade_procedure.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
// Regular procedure for preview profile workflows migration.
// The caller document must set the following attributes: (see: upgrade_1_37_0_to_1_37_1.adoc as example)
// current_operator_version, next_operator_version
:page-partial:

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.

For every workflow `my-workflow` with the `preview` profile you must:

*Pre-operator upgrade steps:*

. If the workflow is configured to use persistence, you must back up the workflow database.
Ensure that your database backup includes all database objects, not just the table's information.

. 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.

. Delete the workflow by using the following command:
+
[source,terminal]
----
$ oc delete -f <my-workflow.yaml> -n <target_namespace>
----

*Post-operator upgrade steps:*

[start=4]
. Ensure that any Kubernetes resource for that workflow, such as the user-provided `ConfigMap` with `application.properties`, is created before you redeploy the workflow.

+
. Redeploy the workflow by using the following command:
+
[source,terminal]
----
$ oc apply -f <my-workflow.yaml> -n <target_namespace>
----
Loading