Repository navigation
Conversation
Collaborator
Author
|
Doh, this should've been a draft. |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The temporary authentication account can be deleted without a replacement, blocking administrator bootstrapping, and the readiness request can hang indefinitely without a client-side timeout.
2 open issues
What changed in this PR
Adds optional config shards to mongodb-runner’s sharded clusters, allowing callers to delegate the transition and readiness checks to the runner.
Changes:
- Adds
configShardCLI and programmatic options, validation, and serialized state. - Implements the transition, readiness polling, and temporary-user handling for authenticated clusters.
- Adds integration tests and usage documentation.
| File | Description |
|---|---|
packages/mongodb-runner/src/mongoserver.ts |
Exposes keyfile contents for authentication detection. |
packages/mongodb-runner/src/mongocluster.ts |
Implements config-shard startup, authentication handling, and serialization. |
packages/mongodb-runner/src/mongocluster.spec.ts |
Tests transitions, authenticated startup, serialization, and topology validation. |
packages/mongodb-runner/src/cli.ts |
Adds the --configShard option. |
packages/mongodb-runner/src/cli.spec.ts |
Tests CLI startup and ls --json reporting. |
packages/mongodb-runner/README.md |
Documents config-shard usage and requirements. |
Review effort: Balanced
| mongos.keyFileContents !== undefined || mongos.isAuth; | ||
| if (!needsCredentials) { | ||
| await mongos.withClient(runTransition); | ||
| } else { |
Comment on lines
+985
to
+990
| const { shards: currentShards } = await client.db('admin').command({ | ||
| listShards: 1, | ||
| // Bound each poll by the remaining time budget so that a | ||
| // stalled mongos cannot hang start() indefinitely. | ||
| maxTimeMS: Math.max(1, deadline - Date.now()), | ||
| }); |
autarch
added a commit
that referenced
this pull request
Nov 5, 2026
Review follow-ups on #963: - On clusters that enforce authentication, configShard now requires at least one configured user. Without one, the temporary transition user would have been the only account on the cluster, and dropping it after the transition would leave no users and a permanently closed localhost exception, locking out any administrator bootstrap. - The transition/readiness clients now set a client-side timeoutMS so a mongos that stops responding cannot hang start() indefinitely (maxTimeMS only bounds server-side execution).
Passing --configShard (or configShard: true in the config file / programmatic options) turns the config server replica set into a config shard once the cluster is up, by running transitionFromDedicatedConfigServer through mongos (MongoDB 5.0+). start waits until the transition completes (the config server appears in listShards), and ls --json reports configShard: true for such clusters, so consumers can distinguish a config shard from a dedicated config server without connecting. This is the topology mongosync's test clusters previously built by running the transition themselves after mongodb-runner finished.
… to 8.0 Adversarial review follow-ups, verified empirically: - With keyfile authentication the transition failed: the localhost exception does not permit transitionFromDedicatedConfigServer, and __system cannot authenticate through mongos without enableTestCommands. Instead, create a temporary root user through the localhost exception, run the transition and readiness poll as that user, create the cluster's own users as it (the localhost exception closes once any user exists and does not reopen after a drop), then drop it. - transitionFromDedicatedConfigServer is new in MongoDB 8.0 (removed in 6.0/7.0 after existing briefly in 5.0); corrected the option docs, CLI help, README, and the error message from 5.0+ to 8.0+. Confirmed on 6.0.x and 7.0.x binaries that the command does not exist there. - Each listShards readiness poll is now bounded by maxTimeMS from the remaining time budget, so a stalled mongos cannot hang start(). - README no longer claims start --json reports configShard (that arrives with the start --json topology output change). - New regression test: config shard with keyfile auth, asserting the temporary user is removed and only the configured user remains.
Review follow-ups on #963: - On clusters that enforce authentication, configShard now requires at least one configured user. Without one, the temporary transition user would have been the only account on the cluster, and dropping it after the transition would leave no users and a permanently closed localhost exception, locking out any administrator bootstrap. - The transition/readiness clients now set a client-side timeoutMS so a mongos that stops responding cannot hang start() indefinitely (maxTimeMS only bounds server-side execution).
autarch
force-pushed
the
11-05-mongodb-runner_config-shard-topology
branch
from
November 6, 2026 21:46
7e34847 to
a5df849
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a
configShardoption to mongodb-runner: for theshardedtopology, after the cluster is up and shards are added, the runner runstransitionFromDedicatedConfigServerthrough mongos, waits until the config server appears inlistShards(sostartreturns with the topology fully usable), and serializesconfigShard: truesols --jsonreports it.Motivated by REP-8055 (mongosync test clusters on mongodb-runner): mongosync currently runs the transition itself in
configureNewClusterand excludes the config shard inGetDataOnlyShardCount; with this option they can passconfigShard: trueand delete their own transition call.Details
--configShard, config-file / programmaticconfigShard: true; rejected with a clear error for standalone/replset topologies.--authclusters, the localhost exception does not permit the transition and__systemcannot authenticate through mongos withoutenableTestCommands. The runner therefore creates a temporary root user through the localhost exception, runs the transition and readiness poll as that user, creates the cluster's own users as it (the localhost exception closes permanently once any user exists), then drops it. A regression test asserts the temporary user is gone afterward.maxTimeMSfrom the remaining time budget.Testing
can start a sharded cluster with a config shard(topology + serialize round trip)can start a sharded cluster with a config shard and keyfile auth(auth path + temp user cleanup)rejects configShard for non-sharded topologiesstarts a config shard cluster and reports it in ls --jsonCaveats
configShardis a top-level option only;shards[i].configShardin a config file is ignored.start --jsonreporting ofconfigShardarrives with feat(mongodb-runner): include full topology in start --json output #962 (serialized topology in start output).