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
# Summary
This PR fixes the behaviour of changing the project in a
MongoDBMultiCluster resource. Multicluster resources have a different
method of computing the member ids of each process in a replicaset
(`replicasets` field in AC). Because of that, it is possible to get
non-sequential ids by doing scaling operations. For example, we start
from this
* mongodb-0-0: id 0
* mongodb-0-1: id 1
* mongodb-1-0: id 2
If we now scale the first cluster up we end up with:
* mongodb-0-0: id 0
* mongodb-0-1: id 1
* mongodb-1-0: id 2
* mongodb-0-2: id 3
If we now change the project, the operator will find an empty AC and
will recalculate the ids it of the replicaset members.
* mongodb-0-0: id 0
* mongodb-0-1: id 1
* mongodb-0-2: id 2
* mongodb-1-0: id 3
But now, member `0-2` has id 2 instead of 3, and member `1-0` has id 3
instead of 2. This will instruct the agents to change the members of the
replicaset, but this change will be rejected, leaving the deployment
stuck. The operator can't retrieve the previous member ids.
In this PR we will now save the member ids we achieved in an annotation,
and whenever there is an empty AC in OM, we try to read the annotation
in case the deployment is being migrated to a new project.
### Other considerations
* The id of a replica set member has to be an integer, so we can't use
the hostnames instead.
* We can bring a future improvement to the id computation method by
using a hash between cluster index and pod index. This way, any id the
operator computes will be consistent and do not require reading the AC.
The issue is that changing the id of a replicaset member is a convoluted
process and migrating the old pseudo-sequential ids to hashed ids is
extremely complex. This means that while there still are deployments
that use these kind of id's we need to back these id's somewhere in case
the deployment is moved to a different project. This idea will be
discussed further.
* If the `MongoDBMultiCluster` is backed up with annotations and then
re-applied to a new project, the annotation will be used to compute the
member ids. This is not an issue, there is no restrictions on these ids
(apart from being an integer and unique). After the initial deployment,
any scaling operations will simply compute new sequential ids.
## Proof of Work
Added unit tests to check that annotations are created and updated
successfully, as well as using the annotation when building the
replicaset.
Also added an E2E test to ensure the resource will become ready.
## Checklist
- [x] Have you linked a jira ticket and/or is the ticket in the title?
- [x] Have you checked whether your jira ticket required DOCSP changes?
- [x] Have you checked for release_note changes?
0 commit comments