Fleet internally uses a limit of 50 BundleDeployments that are created for roll-outs in a single reconciliation loop. This means a partition of 100 clusters with the option to allow only 2 of them to fail will still roll-out 50 BundleDeployments. The user can use partitioning differently and put less clusters into their partitions, but if the labels of their clusters shouldn't be changed and the partitions do make sense to the user, it would be possible for them to keep their partitions by being able to configure the limit of 50 clusters that are created before the conditions of the partition to be rolled out are evaluated.
This change would mostly benefit customers who don't want to add additional labels to their clusters for their partitioning requirements but still want to or need to control how many of them are updated or rolled out at once.
This issue follows up on finding in #2672.
Fleet internally uses a limit of 50 BundleDeployments that are created for roll-outs in a single reconciliation loop. This means a partition of 100 clusters with the option to allow only 2 of them to fail will still roll-out 50 BundleDeployments. The user can use partitioning differently and put less clusters into their partitions, but if the labels of their clusters shouldn't be changed and the partitions do make sense to the user, it would be possible for them to keep their partitions by being able to configure the limit of 50 clusters that are created before the conditions of the partition to be rolled out are evaluated.
This change would mostly benefit customers who don't want to add additional labels to their clusters for their partitioning requirements but still want to or need to control how many of them are updated or rolled out at once.
This issue follows up on finding in #2672.