[SRVLOGIC-196] Rollout operator's deployment when custom configuration changes

[dmartinol]

Description of the change:
Use annotations to rollout the Deployment in prod profile, when the properties ConfigMap changes. In particular, under spec.template.annotations:

• checksum/config: holds the sha256 encoded string of the application.properties key of the properties ConfigMap
• sonataflow.org/restartedAt: the timestamp when the last restart was requested

Motivation for the change:
To update the workflow application whenever the user configuration is updated on the cluster.

Checklist

• Add or Modify a unit test for your change
• Have you verified that all the tests are passing?

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[ricardozanini]

Great work! Just a minor observation, if you don't mind.

[ricardozanini]

@dmartinol can u rebase? The problem was fixed in #332

[dmartinol]

@dmartinol can u rebase? The problem was fixed in #332

done and also fixed the checksum annotation (twice, sorry). updated ADR accordingly

[ricardozanini]

@dmartinol can u rebase? The problem was fixed in #332

done and also fixed the checksum annotation (twice, sorry). updated ADR accordingly

No worries! That's why I suggested checksumConfig, I've had this validation error before 😅

[domhanak]

@dmartinol Please rebase, it should solve the issues with PR checks.

[dmartinol]

@ricardozanini @wmedvede any further feedback?

[ricardozanini]

@domhanak will verify this PR, @dmartinol

[domhanak]

Thanks! Works well I did not run into issues.

Here is apart of the deployment description after I updated its configMap with quarkus.log.level=DEBUG
You can see the new annotations.

Namespace:              sonataflow-operator-system
CreationTimestamp:      Wed, 17 Jan 2024 13:42:12 +0100
Labels:                 app=greeting
                        sonataflow.org/workflow-app=greeting
Annotations:            deployment.kubernetes.io/revision: 3
Selector:               app=greeting,sonataflow.org/workflow-app=greeting
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:       app=greeting
                sonataflow.org/workflow-app=greeting
  Annotations:  sonataflow.org/checksum-config: 42894021dcc8d31a6efc8a2b7faa9d0dc1d777e646ba2d6b141544dfce983f0d
                sonataflow.org/restartedAt: 2024-01-17T12:45:59Z