[SERVER-21577] Fix shardingtest upgradeCluster function to reflect 3.2 upgrade process Created: 19/Nov/15  Updated: 06/Dec/22  Resolved: 02/Feb/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-22282 Update multiVersion/upgrade_cluster t... Closed
Assigned Teams:
Sharding
Operating System: ALL
Sprint: Sharding 10 (02/19/16)
Participants:

 Description   

Shardingtest upgradeCluster upgrades mongos first and this hence the two step upgrade process is needed in jstests because mongos can not connect to mongod 3.0 or less.
Need to fix the upgradeCluster to choose the upgrade order depending of the version it upgrades to.



 Comments   
Comment by Spencer Brody (Inactive) [ 20/Nov/15 ]

I think this is something we're definitely going to want to do sooner than later, otherwise our multi-version testing framework becomes much less useful.

Generated at Thu Feb 08 03:57:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.