[SERVER-48183] Mark sharding/remove2.js as requires_fcv_46 Created: 13/May/20  Updated: 06/Dec/22  Resolved: 14/May/20

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

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Assigned Teams:
Sharding
Operating System: ALL
Participants:
Linked BF Score: 24

 Description   

sharding/remove2.js is used to test the addition and removal of a shard to the cluster. By running it on the sharding_multiversion suite we could incur in possible downgrade of the replica set nodes. In fact on each replicaSet restart the sharding_multiversion suite choose a random version between latest and last-stable. Since we don't support downgrade we shouldn't run this test in the multiversion suite.



 Comments   
Comment by Tommaso Tocci [ 14/May/20 ]

I found the definite cause of the BF-17247 I'll close this and open another SERVER ticket to fix the issue. Thanks max.hirschhorn for always double checking

Comment by Kaloian Manassiev [ 14/May/20 ]

This was done on urge from me, based on my mistaken interpretation that this somehow results in an unplanned/unsupported order of downgrades. However I am just realising that this is actually not the case, because MongoS will be at 4.4 and so will be the Config server, so the downgrade is not an issue.

Comment by Max Hirschhorn [ 13/May/20 ]

Since we don't support downgrade we shouldn't run this test in the multiversion suite.

tommaso.tocci, why is the shard not allowed to be re-added after downgrading the binary version? The thought in SERVER-46749 is that only tests which trigger unclean shutdowns wouldn't be able to successfully downgrade.

Generated at Thu Feb 08 05:16:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.