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
I expected the agent to receive rs0 as _id of the replicaSet when additionalMongodConfig replication.replSetName is used.
Alternatively there could be an override for the replicaSetName under spec directly, so it is used both for the replicaSets._id (agent) and replication.replSetName (mongod).
What happened instead?
It receives mongodb instead.
Screenshots
Additional context
We are looking to migrate 100+ clusters to the operator and this is the last piece in the puzzle.
I confirmed this by stopping the operator and manually changing the _id to rs0 in secret mongodb-config and then seeing the agent become ready.
After starting the operator again, it then undos the changes to the secret, of course.
I had a thorough look through the relevant sources and didn't find a way to fix this with the current implementation.
The automation config builder name is set to the mdb.Name here:
{"statuses":{"mongodb-0":{"IsInGoalState":false,"LastMongoUpTime":1736175160,"ExpectedToBeUp":true,"ReplicationStatus":1}},"mmsStatus":{"mongodb-0":{"name":"mongodb-0","lastGoalVersionAchieved":1,"plans":[{"automationConfigVersion":1,"started":"2025-01-06T13:24:00.086578872Z","completed":null,"moves":[{"move":"Start","moveDoc":"Start the process","steps":[{"step":"StartFresh","stepDoc":"Start a mongo instance (start fresh)","isWaitStep":false,"started":"2025-01-06T13:24:00.08660494Z","completed":"2025-01-06T13:24:09.865099778Z","result":"success"}]},{"move":"WaitAllRsMembersUp","moveDoc":"Wait until all members of this process' repl set are up","steps":[{"step":"WaitAllRsMembersUp","stepDoc":"Wait until all members of this process' repl set are up","isWaitStep":true,"started":"2025-01-06T13:24:09.865192101Z","completed":null,"result":"wait"}]},{"move":"RsInit","moveDoc":"Initialize a replica set including the current MongoDB process","steps":[{"step":"RsInit","stepDoc":"Initialize a replica set","isWaitStep":false,"started":null,"completed":null,"result":""}]},{"move":"WaitFeatureCompatibilityVersionCorrect","moveDoc":"Wait for featureCompatibilityVersion to be right","steps":[{"step":"WaitFeatureCompatibilityVersionCorrect","stepDoc":"Wait for featureCompatibilityVersion to be right","isWaitStep":true,"started":null,"completed":null,"result":""}]}]},{"automationConfigVersion":1,"started":"2025-01-06T13:35:35.257483563Z","completed":"2025-01-06T13:35:39.182499358Z","moves":[{"move":"EnsureAutomationCredentials","moveDoc":"Ensure the automation user exists","steps":[{"step":"EnsureAutomationCredentials","stepDoc":"Ensure the automation user exists","isWaitStep":false,"started":"2025-01-06T13:35:35.257505082Z","completed":"2025-01-06T13:35:39.022009499Z","result":"success"}]},{"move":"AdjustUsers","moveDoc":"Adjust Users","steps":[{"step":"AdjustUsers","stepDoc":"Adjust Users","isWaitStep":false,"started":"2025-01-06T13:35:39.022147572Z","completed":"2025-01-06T13:35:39.182354797Z","result":"success"}]}]}],"errorCode":104,"errorString":"\u003cmongodb-0\u003e [14:51:42.024] Failed to find a plan!","waitDetails":{"WaitAllRsMembersUp":"[]","WaitAuthSchemaCorrect":"auth schema will be updated by the primary","WaitCanStartFresh":"process not up","WaitCannotBecomePrimary":"Wait until the process is reconfigured with priority=0 by a different process","WaitDefaultRWConcernCorrect":"waiting for the primary to update defaultRWConcern","WaitForResyncPrimaryManualInterventionStep":"A resync was requested on a primary. This requires manual intervention","WaitHealthyMajority":"[]","WaitMultipleHealthyNonArbiters":"[]","WaitNecessaryRsMembersUpForReconfig":"[]","WaitPrimary":"This process is expected to be the primary member. Check that the replica set state allows a primary to be elected","WaitProcessUp":"The process is running, but not yet responding to agent calls","WaitResetPlacementHistory":"config servers haven't seen the marker"}}}
The verbose agent logs of the faulty members:
[2025-01-06T14:53:42.436+0000] [.warn] [src/director/director.go:computePlan:297] <mongodb-0> [14:53:42.436] ... No plan could be found - not in goal state because of:
[All the following are false:
['desiredState.ReplSetConf' != <nil> ('desiredState.ReplSetConf' = ReplSetConfig{id=mongodb,version=0,commitmentStatus=false,configsvr=false,protocolVersion=1,forceProtocolVersion=false,writeConcernMajorityJournalDefault=,members={id:0,HostPort:mongodb-0.service-mongodb.mongodb.svc.test.kubernetes.local.mixxt.net:27017,ArbiterOnly:falsePriority:1,Hidden:false,SecondaryDelaySecs:0,Votes:1,Tags:map[]},{id:1,HostPort:mongodb-1.service-mongodb.mongodb.svc.test.kubernetes.local.mixxt.net:27017,ArbiterOnly:falsePriority:1,Hidden:false,SecondaryDelaySecs:0,Votes:1,Tags:map[]},{id:2,HostPort:mongodb-2.service-mongodb.mongodb.svc.test.kubernetes.local.mixxt.net:27017,ArbiterOnly:falsePriority:1,Hidden:false,SecondaryDelaySecs:0,Votes:1,Tags:map[]},settings=map[]})]
['currentState.ReplSetConf.Id' != 'desiredState.ReplSetConf.Id' : (rs0) vs. (mongodb)]
Also seen previously:
(InvalidReplicaSetConfig) Rejecting initiate with a set name that differs from command line set name, initiate set name: mongodb, command line set name: rs0
The text was updated successfully, but these errors were encountered:
What did you do to encounter the bug?
Steps to reproduce the behavior:
--replSet=rs0
in a StatefulSet namedmongodb
What did you expect?
I expected the agent to receive
rs0
as _id of the replicaSet when additionalMongodConfigreplication.replSetName
is used.Alternatively there could be an override for the replicaSetName under
spec
directly, so it is used both for the replicaSets._id (agent) and replication.replSetName (mongod).What happened instead?
It receives
mongodb
instead.Screenshots
Additional context
We are looking to migrate 100+ clusters to the operator and this is the last piece in the puzzle.
I confirmed this by stopping the operator and manually changing the _id to
rs0
insecret mongodb-config
and then seeing the agent become ready.After starting the operator again, it then undos the changes to the secret, of course.
I had a thorough look through the relevant sources and didn't find a way to fix this with the current implementation.
The automation config builder name is set to the
mdb.Name
here:mongodb-kubernetes-operator/controllers/replica_set_controller.go
Line 522 in 85086f7
and then
Id
is set tob.name
here:mongodb-kubernetes-operator/pkg/automationconfig/automation_config_builder.go
Line 380 in 85086f7
b.name
is also used to setreplication.replSetName
here:mongodb-kubernetes-operator/pkg/automationconfig/automation_config_builder.go
Line 325 in 85086f7
Did I miss something?
If I could contribute a fix for this, what should I look out for in my implementation to make it acceptable?
Also seen previously:
The text was updated successfully, but these errors were encountered: