[SERVER-55140] Fix how ShardingTest handles setParameters Created: 10/Mar/21 Updated: 02/Apr/21 Resolved: 01/Apr/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Shreyas Kalyan | Assignee: | Benjamin Caimano (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Security 2021-04-05 | ||||||||
| Participants: | |||||||||
| Description |
|
When adding setParameters for sharding tests like this:
The test runner adds an extra setParameter - migrationLockAcquisitionMaxWaitMS for the mongos which causes it to fail to start. Instead, a user has to add set parameters like this - setParameter: "param1=val", which does not allow a user to specify multiple setParameters in an intuitive way (or possibly at all). See this example for how the ShardingTest set parameter needs to be specified.
|
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 01/Apr/21 ] |
|
We have decided not to pursue this at this time due to its small impact on our test efficacy. For future reference, ShardingTest and ReplSetTest have two potential sources of unexpected behavior:
|