canonical / canonical/mongodb-operator
Sometimes Failing to add shard to Config server when TLS enabled
- Dominant language
- HCL
- Stars
- 14
- Forks
- 15
- Avg merge
- 9h 44m
- Merged PRs (30d)
- 17
Description
The current issue happens on the `tls_sharding` test, [example run](https://github.com/canonical/mongodb-operator/actions/runs/8896004004/job/24437953165)
```
unit-config-server-0: 17:44:18 ERROR unit.config-server/0.juju-log config-server:6: Failed to add shard shard-one to the config server, error=OperationFailure('Could not find host matching read preference *** mode: "primary" *** for set shard-one, full error: ***\'ok\': 0.0, \'errmsg\': \'Could not find host matching read preference *** mode: "primary" *** for set shard-one\', \'code\': 133, \'codeName\': \'FailedToSatisfyReadPreference\', \'$clusterTime\': ***\'clusterTime\': Timestamp(1714499057, 2), \'signature\': ***\'hash\': b\'\\xcc\\x19iw\\x99\\xf7\\x15\\x13\\xa1\\x97\\x80jK\\xb8\\x16\\xae\\x16%j\\xce\', \'keyId\': 7363716618628628505***, \'operationTime\': Timestamp(1714499057, 2)***')
unit-config-server-0: 17:44:18 ERROR unit.config-server/0.juju-log config-server:6: Failed to add shard-one to cluster
unit-config-server-0: 17:44:18 ERROR unit.config-server/0.juju-log config-server:6: Deferring _on_relation_event for shards interface since: error=OperationFailure('Could not find host matching read preference *** mode: "primary" *** for set shard-one, full error: ***\'ok\': 0.0, \'errmsg\': \'Could not find host matching read preference *** mode: "primary" *** for set shard-one\', \'code\': 133, \'codeName\': \'FailedToSatisfyReadPreference\', \'$clusterTime\': ***\'clusterTime\': Timestamp(1714499057, 2), \'signature\': ***\'hash\': b\'\\xcc\\x19iw\\x99\\xf7\\x15\\x13\\xa1\\x97\\x80jK\\xb8\\x16\\xae\\x16%j\\xce\', \'keyId\': 7363716618628628505***, \'operationTime\': Timestamp(1714499057, 2)***')
unit-config-server-0: 17:44:39 ERROR unit.config-server/0.juju-log config-server:7: Failed to add shard shard-two to the config server, error=OperationFailure("Authentication failed., full error: ***'ok': 0.0, 'errmsg': 'Authentication failed.', 'code': 18, 'codeName': 'AuthenticationFailed', '$clusterTime': ***'clusterTime': Timestamp(1714499078, 1), 'signature': ***'hash': b'\\xa3\\xe1\\xce\\xeb7\\x16w\\xb2,H~\\x86\\xad0\\xf1c\\xd4\\r\\xc5^', 'keyId': 7363716618628628505***, 'operationTime': Timestamp(1714499078, 1)***")
unit-config-server-0: 17:44:39 ERROR unit.config-server/0.juju-log config-server:7: shard-two shard does not have the same auth as the config server.
```
Contributor guide
Research direction
Start by running the `tls_sharding` test and reviewing the linked GitHub Actions run. Trace the config-server shard-add operation for the read-preference and authentication failures shown in the logs. Done means the test reliably adds the shards to the config server with TLS enabled and no deferred relation event.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- mongodb
- Domain
- databases, distributed-systems, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100