[SERVER-32468] Use a 1-node CSRS in non-stepdown sharding passthroughs tests Created: 27/Dec/17  Updated: 30/Oct/23  Resolved: 26/Jan/18

Status: Closed
Project: Core Server
Component/s: Sharding, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.6.3, 3.7.2

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Robert Guo (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-40063 jstestfuzz_sharded_continuous_stepdow... Closed
related to SERVER-32920 Avoid overriding read preference for ... Closed
is related to SERVER-31670 Change replica set fixture used by re... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: TIG 2018-1-29, TIG 2018-02-12
Participants:

 Description   

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.



 Comments   
Comment by Githook User [ 14/Feb/18 ]

Author:

{'email': 'robert.guo@10gen.com', 'name': 'Robert Guo', 'username': 'guoyr'}

Message: SERVER-32468 Use a 1-node CSRS in non-stepdown sharding passthroughs tests

(cherry picked from commit 0aeb5ce7e8d4a190dac43fd110533eef149f7880)
Branch: v3.6
https://github.com/mongodb/mongo/commit/47fc424ca082fc11d04fe0dedc550a3b87e689c5

Comment by Githook User [ 26/Jan/18 ]

Author:

{'name': 'Robert Guo', 'email': 'robert.guo@10gen.com', 'username': 'guoyr'}

Message: SERVER-32468 Use a 1-node CSRS in non-stepdown sharding passthroughs tests
Branch: master
https://github.com/mongodb/mongo/commit/0aeb5ce7e8d4a190dac43fd110533eef149f7880

Comment by Kyle Suarez [ 28/Dec/17 ]

Another benefit is that I find the tests to go faster as well, and tend to use only 1 node in the CSRS when doing local testing (Charlie's suggestion).

Comment by Max Hirschhorn [ 27/Dec/17 ]

Thanks kaloian.manassiev, I moved this back to TIG since we can make the necessary changes to resmoke.py now that I've gotten your confirmation.

Comment by Kaloian Manassiev [ 27/Dec/17 ]

I don't see any problem with doing that for the passthrough tests - it sounds like a good idea to me, from efficiency point of view. All the config server features should work just fine with a single node in the set.

As for the dedicated sharding suites - we have always been saying that "if it is failing in Evergreen due to slow machine, chances are that customers are experiencing the same problems", so this would force us to make the product better". However, I think overwhelming majority of the build failures we are getting are just noise in the tests.

Based on this, I am fine with doing it for the dedicated sharding tests, other than the step down suite.

Generated at Thu Feb 08 04:30:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.