[SERVER-22424] Write test for CSRS using different numbers of config servers Created: 01/Feb/16 Updated: 07/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sharding-common-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Cluster Scalability
|
| Sprint: | Sharding 10 (02/19/16) |
| Participants: |
| Description |
|
Currently we only test CSRS with 3 config servers. We should probably test at least the following configurations:
Probably can just write a test that does a bunch of basic operations: CRUD on sharded/unsharded collections, splits, migrates, creating and dropping collections and databases, etc, then run that test against these different config server configurations |
| Comments |
| Comment by Spencer Brody (Inactive) [ 02/Feb/16 ] |
|
pasette - yeah, it would be fairly trivial to add new test suites that run the existing sharding tests with various numbers of config servers. I was just worried about adding too many redundant sharding suites adding too much usage to evergreen for low payoff. I guess if we made the suite only run once per day or something it wouldn't be too bad. Adding more suites is definitely an easier approach and will get us better coverage. So long as we don't mind the extra MCI usage, we should probably go with that approach. |
| Comment by Daniel Pasette (Inactive) [ 01/Feb/16 ] |
|
is it possible to adapt the existing sharding suite tests (or some subset within) to use variable numbers of config servers? |