You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CLOUDP-288551: Block scaling both ways at runtime (#4099)
# Summary
This PR blocks reconciliation in case we attempt to scale components up
and down at the same time (both ways).
When changing member distribution of a component, they should only scale
down, or up.
A component can be a shard, config servers or mongos
E.g (for a distribution of a component over 3 clusters):
- Scaling from 1 2 2 to 3 3 2 would be valid
- Scaling from 2 2 2 to 1 2 3 would be invalid, as the component is
scaling from 1 to 2 members on cluster 1, but from 2 to 3 on cluster 3.
Multiple cases are illustrated in unit tests.
We need to be defensive in these cases, because it can create
inconsistencies in the behaviour of the operator. For example when we
decide if we should publish the automation config first, we check at the
cluster level, so we can detect that we scale down, whereas the global
replica set (across all clusters) is scaling up.
This change will also impact single cluster sharded clusters (e.g
scaling up shards, but scaling down config servers)
**Note:** we chose to do this check at runtime rather than in webhooks.
Doing it at the webhook level would require to duplicate a lot of logic
from the reconciler, to compute the desired configuration based on shard
overrides, member config...
With the scalers available, it is much easier and makes more sense to do
it at runtime.
## List of changes
- New method in sharded reconciler to block reconciliation if needed.
- Fixed a bug which might cause losing the current sizes from the
deployment state when upgrading the operator from <=1.27
(10gen/ops-manager-kubernetes@0fa2d50)
- Unit test for this mechanism in various scaling scenarios.
- Modified the `MultiClusterReplicaSetScaler` interface, to avoid type
casting.
- Fixed E2E tests that were attempting both ways reconciliation.
- Added a constant for "slaney", the default name of a sharded cluster
in unit tests.
## Documentation
This ticket will be closed with documentation changes required to update
our public documentation.
## Proof of Work
Unit test `TestBlockReconcileScalingBothWays`
Example error message:
```
Cannot perform scale up and scale down operations at the same time. Scaling Up: [Component=shard idx 0, Cluster=__default, Current=0, Desired=2;], Scaling Down: [Component=configSrv, Cluster=__default, Current=3, Desired=2;]"
```
**Note:** The e2e test `e2e_operator_upgrade_sharded_cluster` is failing
and we are aware of that. It is related to how the state configmap is
handled during a migration. We opened this PR nonetheless as this
failure is not directly related to these changes, but we are working on
adding a fix.
---------
Co-authored-by: Łukasz Sierant <[email protected]>
Copy file name to clipboardExpand all lines: RELEASE_NOTES.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,9 @@
2
2
<!-- Next Release -->
3
3
# MongoDB Enterprise Kubernetes Operator 1.32.0
4
4
5
+
## New Features
6
+
***MongoDB**: To ensure the correctness of scaling operations, a new validation has been added to Sharded Cluster deployments. This validation restricts scaling different components in two directions simultaneously within a single change to the YAML file. For example, it is not allowed to add more nodes (scaling up) to shards while simultaneously removing (scaling down) config servers or mongos. This restriction also applies to multi-cluster deployments. A simple change that involves "moving" one node from one cluster to another—without altering the total number of members—will now be blocked. It is necessary to perform a scale-up operation first and then execute a separate change for scaling down.
7
+
5
8
## Bug Fixes
6
9
* Fixes the bug when status of `MongoDBUser` was being set to `Updated` prematurely. For example, new users were not immediately usable following `MongoDBUser` creation despite the operator reporting `Updated` state.
7
10
* Fixed a bug causing cluster health check issues when ordering of users and tokens differed in Kubeconfig.
Copy file name to clipboardExpand all lines: controllers/operator/mongodbshardedcluster_controller.go
+74-9Lines changed: 74 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -91,6 +91,21 @@ type ShardedClusterDeploymentState struct {
91
91
Status*mdbv1.MongoDbStatus`json:"status"`
92
92
}
93
93
94
+
// updateStatusFromResourceStatus updates the status in the deployment state with values from the resource status with additional ensurance that no data is accidentally lost.
95
+
// In a rare situation when we're performing an upgrade of the operator from non-deployment state version (<=1.27) the migrateToNewDeploymentState
96
+
// function correctly migrates the sizes of the cluster, but then, in case of an early return (in case of any error or waiting too long for the sts/agents)
97
+
// the updateStatus might clear the migrated data.
98
+
// This function ensures we're copying the status, but at the same time we're not losing those sizes from the deployment state.
99
+
// The logic of updateStatus in the reconciler works on options. If the option is not passed, the value is not updated, but it's also not cleared if the option is not passed.
100
+
// Early returns with updateStatus don't pass any options, so the calculated status shouldn't clear the sizes we've just calculated into the deployment state.
returnr.commonController.updateStatus(ctx, resource, workflow.Failed(xerrors.Errorf("Failed to write deployment state after updating status: %w", err)), log, nil)
0 commit comments