-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding, Testing Infrastructure
-
None
-
Fully Compatible
-
v3.6
-
TIG 2018-1-29, TIG 2018-02-12
Akin to the idea behind SERVER-31670 of reducing the number of unexpected elections observed in our tests, I'd like to propose that we use
- a 3-node CSRS where all nodes have votes=1 and priority=1 when the test suite attempts to step down the CSRS primary, and
- a 1-node CSRS for all other cases.
This would mean the following test suites would run with a 1-node CSRS
- aggregation_sharded_collections_passthrough.yml
- causally_consistent_jscore_passthrough.yml
- causally_consistent_jscore_passthrough_auth.yml
- change_streams_mongos_passthrough.yml
- change_streams_sharded_collections_passthrough.yml
- change_streams_secondary_reads.yml
- integration_tests_sharded.yml
- jstestfuzz_sharded.yml
- jstestfuzz_sharded_causal_consistency.yml
- jstestfuzz_sharded_session.yml
- sharded_causally_consistent_jscore_passthrough.yml
- sharded_collections_jscore_passthrough.yml
- sharding_gle_auth_basics_passthrough.yml
- sharding_jscore_op_query_passthrough.yml
- sharding_jscore_passthrough.yml
and only jstestfuzz_sharded_continuous_stepdown.yml would continue to use a 3-node replica set. Is the Sharding team agreeable to this proposal? I'd also be curious to know if this is something we'd consider doing for sharding-related tests that aren't interested in specifically how collection metadata operates are processed.
- is related to
-
SERVER-31670 Change replica set fixture used by replica_sets_jscore_passthrough to make its secondary have zero votes
- Closed
- related to
-
SERVER-40063 jstestfuzz_sharded_continuous_stepdown.yml is running with a 1-node CSRS on the 3.6 branch
- Closed
-
SERVER-32920 Avoid overriding read preference for the config server in passthrough tests.
- Closed
- mentioned in
-
Page Loading...