[SERVER-27722] Write tests for mixVersion, upgrade/dowgrade scenario for logical clock Created: 17/Jan/17 Updated: 06/Dec/17 Resolved: 23/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.5.1 |
| Fix Version/s: | 3.5.10 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Jack Mulrow |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2017-06-19, Sharding 2017-07-10 |
| Participants: |
| Description |
|
The mongo config server should not enable key generation until the featureCompatibilityVersion = 3.6 is set The existing multiversion test suite. https://github.com/mongodb/mongo/blob/master/jstests/multiVersion/upgrade_cluster.js upgrade order is need to add a test case where
once mongod is upgraded
once mongos are upgraded and
once featureCompatibilityVersion = 3.6 is set
the downgrade should check this in reverse. |
| Comments |
| Comment by Githook User [ 23/Jun/17 ] |
|
Author: {u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'}Message: |
| Comment by Misha Tyulenev [ 12/Jun/17 ] |
|
jack.mulrow yes implementing this scenario is required but can be split off into a separate jira that we can address later |
| Comment by Jack Mulrow [ 12/Jun/17 ] |
|
misha.tyulenev |
| Comment by Misha Tyulenev [ 12/Jun/17 ] |
|
jack.mulrow here are the clarifications: |
| Comment by Jack Mulrow [ 12/Jun/17 ] |
|
misha.tyulenev couple questions:
|
| Comment by Randolph Tan [ 09/Jun/17 ] |
|
The ticket looks good to me. We have to double check the downgrade procedure: It might involve sending featureCompatibilityVersion to 3.4. |
| Comment by Misha Tyulenev [ 08/Jun/17 ] |
|
renctan could you please take a look and lmk the feedback? Thanks! |