[SERVER-84153] Sharded cluster fixture set up does not account for proper multiversion setup Created: 13/Dec/23  Updated: 10/Jan/24  Resolved: 10/Jan/24

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

Type: Bug Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Marcos José Grillo Ramirez
Resolution: Fixed Votes: 0
Labels: auto-reverted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-84334 Introduce maintenance mode on Shardin... Closed
is depended on by SERVER-79159 Track unsharded collections on upgrade Open
Problem/Incident
Assigned Teams:
Catalog and Routing
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22
Participants:
Linked BF Score: 160

 Description   

Several test suites use the ShardedClusterFixture to set up a sharded cluster before running specific tests, like for example sharding_jscore_passthrough. In the setup code the internal ReplicaSetFixture setup function is being called, and here the multiversion scenario is being considered, effectively running the setFeatureCompatibilityVersion command immediately after starting the node. This is done in case we want to set up a mixed binaries replica set, which works fine in the ReplicaSetFixture, but, it is problematic for a sharded cluster because it implies that the setFeatureCompatibilityVersion command is going to be called directly in a shard, which is not a valid use case.

The purpose of this ticket is to properly set up a sharded cluster with multiversion binaries. We could for example change the ShardedClusterFixture setup, to detect that we're setting up a multiversion cluster (similarly to ReplicaSetFixture), and instead of starting the node with --shardsvr, simply run the normal ReplicaSetFixture setup (which will effectively set the proper FCV), and then restart it as a shard.



 Comments   
Comment by Githook User [ 10/Jan/24 ]

Author:

{'name': 'Marcos Grillo', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}

Message: SERVER-84153 Use ShardingState API to determine whether a replica set is a shard in setFeatureCompatibilityVersion command (#17916)

GitOrigin-RevId: 11b13362d48d9f3aadb4eabf53666f731a1bb508
Branch: master
https://github.com/mongodb/mongo/commit/5a671c207aeab471ef3029262342813d4aec57b4

Comment by Githook User [ 05/Jan/24 ]

Author:

{'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com', 'username': ''}

Message: Revert "SERVER-84153 Use ShardingState API to determine whether a replica set is a shard in setFeatureCompatibilityVersion command (#17682)"

This reverts commit ca522cdcb59570a27902a0634a94d073ba8d7bcd.

GitOrigin-RevId: a8701ad28bc6f6284e17c94e1825f4e355ebb42e
Branch: master
https://github.com/mongodb/mongo/commit/4fd7c7b5bbeeda30c026ed384a8c17a068c42e94

Comment by Githook User [ 05/Jan/24 ]

Author:

{'name': 'Marcos Grillo', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}

Message: SERVER-84153 Use ShardingState API to determine whether a replica set is a shard in setFeatureCompatibilityVersion command (#17682)

GitOrigin-RevId: ca522cdcb59570a27902a0634a94d073ba8d7bcd
Branch: master
https://github.com/mongodb/mongo/commit/ee7ae38acbdc313892e1cb342f8e4ce954ec895a

Generated at Thu Feb 08 06:54:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.