SRVLOGIC-682: Operator, DI, JS and Workflows migration from OSL 1.36.0 to OSL 1.37.0 #128
Conversation
|
@wmedvede: This pull request references SRVLOGIC-682 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
✅ Deploy Preview for jazzy-shortbread-5f62b7 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Hi @ricardozanini , @domhanak , @kaldesai , |
| === Overall upgrade procedure | ||
|
|
||
| It is recommended to read and understand all the steps of the procedure before executing. | ||
| Interested parties might automate the procedure according to their convenience or infrastructure, for example, keeping all the `SonataFlow` CRDs in a GitHub repository, might help considerably to implement automation, etc. |
There was a problem hiding this comment.
| Interested parties might automate the procedure according to their convenience or infrastructure, for example, keeping all the `SonataFlow` CRDs in a GitHub repository, might help considerably to implement automation, etc. | |
| Interested parties might automate the procedure according to their convenience or infrastructure, for example, keeping all the `SonataFlow` CRs in a GitHub repository, might help considerably to implement automation, etc. |
CRDs (Custom Resource Definition) are the definitions installed by the operator. The end-user manifest is just the CR (Custom Resource).
|
|
||
| *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. |
There was a problem hiding this comment.
Do we really need to delete the CMs? Since they hold the same name as the CR, only backing up the CR should be enough, no? Once we start reconciliating again, the CMs will be re-attached to the CR.
There was a problem hiding this comment.
Another Q, why are we deleting the CRs for this upgrade? Have we broken the CR API?
There was a problem hiding this comment.
The CM with the user defined properties is deleted as part of the WF deletion. Users must backup it to not loose potential configs.
Other user maually created CMs maybe not, but if we remove some CMs and other not, the upate will look werid.
Or, if user makes any error and remove the namespace, or modify the wrong resoruce as part of the manipulations, might fall introubles.
There was a problem hiding this comment.
Why are we deleting and recreating the CRs? To update to the new image? Something that users will ask soon is the automatic upgrade, hence rolling update the deployed workflows based on labels and so on.
|
|
||
| [#workflows_preview_profile] | ||
| ==== Workflows with the `preview` profile | ||
| Every workflow with the `preview` profile must be deleted before applying the operator upgrade the version 1.37.0, and then, redeployed after the upgrade is complete. |
There was a problem hiding this comment.
Here's I also have a Q.. Theoretically, the operator can rebuild the image and upgrade it automatically, right?
There was a problem hiding this comment.
This is something we talked about in the beginning. During the different version updates, different "manual" updates where required, e.g., if persistence was enabled in 1.34.0, to move to 1.35.0 users had to execute manual db_script for updating the DB, etc. And thus, considering that the preview profile is mostly for "testing" experimenting an environment the most close as possible to the production recommended gitops profile, rather than having to consdier particular situations from version update to version update, not only to start a new bui, I think it's better to keep a common pattern.
| sonataflow-platform-data-index-service-2222222222 registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel9:1.37.0 | ||
| ---- | ||
| + | ||
| Following the example above, the old 1.36.0 `ReplicaSet` `sonataflow-platform-data-index-service-1111111111` must be deleted with the following command: |
There was a problem hiding this comment.
We might do this automatically in the future since the operator manager knows its version.
There was a problem hiding this comment.
maybe yes, but not in this version.
There was a problem hiding this comment.
Yes, we can add it to the backlog
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ricardozanini, wmedvede The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 participants
No description provided.