[SERVER-25549] re-enable read_only_sharded suite Created: 10/Aug/16 Updated: 31/Oct/16 Resolved: 19/Oct/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.0-rc2 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2016-08-29, Sharding 2016-10-31 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Because these tests restart a shard in queryableBackupMode, they must provide the shardIdentity document for the restarted shard to use through the overrideShardIdentity startup parameter. However, this parameter must be passed through a yaml configuration file (by design). Since the shardIdentity document must contain a valid config connection string, we need to add a workaround to either: 1) be able to know before-hand what the config connection string will be, and create a dummy yaml config file in jstests/libs, OR and point the restarted shard to the yaml config file. |
| Comments |
| Comment by Githook User [ 19/Oct/16 ] |
|
Author: {u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 02/Sep/16 ] |
|
Between the following options:
We decided on the latter. Additional note: Unlike the way queryableBackupMode is used in production by Cloud, currently in the read_only_sharded suite, the original config servers are used by the shards even after they're restarted in queryableBackupMode. |
| Comment by Kamran K. [ 02/Sep/16 ] |
From a testability perspective, #1 seems like a more robust solution because you'd be working with fixed data, which makes it easier to debug failures. If that solution is not feasible at this time (or seems like it would not adequately test the scenario), then you can use runProgram to write content to disk, like jstests/libs/host_ipaddr.js does. |
| Comment by Spencer Brody (Inactive) [ 30/Aug/16 ] |
|
Why does this only apply to find.js and get_more.js, but not all the tests in the read_only_sharded suite? |