docs: document transitionFrom for smooth ClusterProfile/Profile trans… - #787
Conversation
|
Checking |
egrosdou01
left a comment
egrosdou01
left a comment
There was a problem hiding this comment.
A few changes to make the docu more ingestible.
|
|
||
| If you simply relabel the cluster so it stops matching **A** at the same time it starts matching **B**, Sveltos's default `stopMatchingBehavior` (`WithdrawPolicies`) removes everything **A** deployed, including uninstalling the Helm release for the CNI, before **B** installs it again. That uninstall/reinstall cycle is the outage you're trying to avoid. | ||
|
|
||
| !!! note |
There was a problem hiding this comment.
!!! Note
The overlap-then-cutover technique on this page still works. However, for a simpler version bump, transitionFrom provides an in-place handover. It only requires a single label change. There is no overlap window to time and no second label to introduce. It also covers raw manifests and Kustomize output, not just Helm charts.
Interested in the overlap-based approach? Keep reading. This is useful if we want the old ClusterProfile to act as a live fallback while it matches. Otherwise, check out transitionFrom for a simpler option.
|
|
||
| ## The Problem | ||
|
|
||
| A common operational pattern is moving a cluster from one `ClusterProfile` to another that deploys mostly the same resources, just at a different version or configuration. For example: a cluster matches `sbom-scanner-v1` via the label `sbom: v1`. `sbom-scanner-v1` and `sbom-scanner-v2` deploy the same set of resources, just at different versions. The operator wants to move the cluster to `sbom-scanner-v2` by changing the cluster's label from `sbom: v1` to `sbom: v2`. |
There was a problem hiding this comment.
A common pattern is moving a cluster from one ClusterProfile to another. This usually involves the same resources but with a different version or setup. For example, a cluster matches sbom-scanner-v1 via the label sbom: v1. sbom-scanner-v1 and sbom-scanner-v2 deploy the same set of resources, just at different versions. The operator wants to move the cluster to sbom-scanner-v2 by changing the cluster's label from sbom: v1 to sbom: v2.
Changing the label to switch from sbom-scanner-v1 to sbom-scanner-v2 will undeploy everything managed by sbom-scanner-v1. Then, it will deploy sbom-scanner-v2, including any shared resources. This happens because sbom-scanner-v1 and sbom-scanner-v2 work in separate loops. These loops are independent and unsynchronized, so there is no guarantee of order between them. As a result, sbom-scanner-v1 can finish its teardown before sbom-scanner-v2 even starts deploying. A plain label swap always undeploys-then-redeploys, even when the two profiles are nearly identical.
|
|
||
| With both `ClusterProfiles` created, changing a cluster's label from `sbom: v1` to `sbom: v2` in a single change is enough: `sbom-scanner-v1`'s resources stay in place until `sbom-scanner-v2` is `Provisioned` on that cluster, and any resource both profiles manage in common is updated in place rather than deleted and recreated. | ||
|
|
||
| ## Restrictions |
There was a problem hiding this comment.
Can you make this paragraph clearer. I am not sure what you are trying to say here.
4a48852 to
e06fa76
Compare
2 participants
…itions