[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: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||||||
| Sprint: | TIG 2018-1-29, TIG 2018-02-12 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Akin to the idea behind
This would mean the following test suites would run with a 1-node CSRS
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: (cherry picked from commit 0aeb5ce7e8d4a190dac43fd110533eef149f7880) |
| Comment by Githook User [ 26/Jan/18 ] |
|
Author: {'name': 'Robert Guo', 'email': 'robert.guo@10gen.com', 'username': 'guoyr'}Message: |
| 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. |