Verify and Document "rollout'

[manno]

Fleet supports rollout options. We don't exercise them in tests, yet.

The existing documentation https://fleet.rancher.io/ref-fleet-yaml mentions several options. How would an example for canary deployments look like? Can we also do blue/green?

• [ ] clarify docs: clusters are partitioned, but status is updated on bundles. Rollout decisions, unavailable, are taken for bundles.
• [ ] how does auto-partitioning work, does 10% of 4 clusters result in 1 partition?
• [ ] unit test for https://github.com/rancher/fleet/blob/main/internal/cmd/controller/target/rollout.go, does manual partitioning really distribute the remaining partitions as stated in the docs?
• [ ] clarify: rollout doesn't influence deployment options, it's just about targeting bundles at clusters.
• [ ] unit test limits: only 50 targets taken into account, only <200 clusters per partition?
• [ ] integration test targeting for unavailable: bundledeployment is not ready, or bundledeployment stagedID not equal to ID
• [ ] examples for docs

[aDisplayName]

Thank you for raising this issue up.

I'm very interested in canary deployment for our production environment.

Here are some more questions I have on partitions:

• Are there a dependency / deployment order among user defined partitions?
• How to configure the rollout strategy so that the bundle deployment failure of preceding partitions will block the succeeding dependent partition from being deployed with the same bundle?
• What is the condition to consider the deployment to one partition has failed? If the destination cluster is simply offline, will it cause the deployment to the partition where it belongs to fail?
• For all clusters not selected in the partition definition, are they being deployed to after all the clusters part of the partitions defined in partitions?

[weyfonk]

#2891 provides an example to document.

[p-se]

integration test targeting for unavailable: bundledeployment is not ready, or bundledeployment stagedID not equal to ID

Handled by unit tests.

how does auto-partitioning work, does 10% of 4 clusters result in 1 partition?

Answered in sub-task.

unit test for main/internal/cmd/controller/target/rollout.go, does manual partitioning really distribute the remaining partitions as stated in the docs?

Answered in sub-tasks, unit test created.

unit test limits: only 50 targets taken into account, only <200 clusters per partition?

50 is the maximum of BundleDeployments created in one reconciliation loop. This makes sure that maxUnavailable is evaluated for partitions larger than 50 clusters an prevents the creation of all BundleDeployments of a partition with a maxUnvailable set to less than a 100%.

200 is the amount of clusters necessary for auto-partitioning not to be disabled. Everything below 200 clusters effectively disables auto-partitioning, which results in all clusters being put into a single partition.

Rest is a docs addition