[SERVER-24855] add a suite that composes continuous_config_stepdown and last_stable_mongos functionality Created: 30/Jun/16  Updated: 06/Dec/22  Resolved: 18/Jan/18

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) 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
is duplicated by SERVER-25108 test addShard and removeShard from le... Closed
Assigned Teams:
Sharding
Sprint: Sharding 2016-08-29
Participants:

 Description   

I thought of this while writing upgrade/compatibility code for ANSA. We don't have any suite that does continuous config stepdown with a legacy mongos.



 Comments   
Comment by Kaloian Manassiev [ 18/Jan/18 ]

I do not see how stepping down the config server in a multi-version environment would exercise the backwards compatibility code more than the regular multi-version suite already does. All the config server metadata logic is already exercised but the regular stepdown suites for the respective versions (starting in 3.2) and the metadata commands are exercised by the stepdown suite in master.

Based on this I don't think such suite is valuable and I am closing this ticket as Won't Fix.

Comment by Dianna Hohensee (Inactive) [ 18/Jan/18 ]

This might be great to add to the Move Metadata Commands to Config Server project (PM-696). Specifically testing old mongos that have the metadata commands, with the new config servers that have the metadata commands, and interrupting the config server's backwards compatibility code, would be nice. Though we do already have the last stable mongos suite covering this, just not harassing the config servers with stepdown craziness, and the shards are mixed version in that suite.

Comment by Max Hirschhorn [ 18/Jan/18 ]

Thanks dianna.hohensee, I'm moving this ticket back to the Sharding team to either close as "Won't fix" or put it on their backlog.

Comment by Dianna Hohensee (Inactive) [ 18/Jan/18 ]

max.hirschhorn, this suite is about legal partially binary upgraded cluster testing. The 3.8 upgrade/downgrade work is around the FCV part of upgrade, once the cluster is fully upgrade in terms of binary version and is binary version consistent. So this is unrelated to the 3.8 upgrade/downgrade project.

Comment by Max Hirschhorn [ 18/Jan/18 ]

kevin.duong, I think I was waiting for esha.maharishi to have been back from vacation in order to discuss it with her, but it has been so long that it's fallen off my radar. I'm not currently equipped to understand the value of the proposed test suite as compared to other testing efforts around mixed-version clusters. dianna.hohensee, maria.vankeulen, does this fit in anywhere with the generic upgrade/downgrade work for the 3.8 development cycle?

Comment by Kevin Duong [ 18/Jan/18 ]

max.hirschhorn What is the state of this ticket? Do we need to pull it one of TIG's iteration plannings?

Comment by Kaloian Manassiev [ 14/Nov/17 ]

max.hirschhorn, I believe we moved it to TIG more as way to get some decision from you about whether having a suite like that even makes sense. I am on the opinion that this suite doesn't give us any significant additional coverage for the extra AWS cost, but I am not strongly opposed to it.

Comment by Max Hirschhorn [ 14/Nov/17 ]

kaloian.manassiev, greg.mckeon, it is the preference of the TIG team for engineers to own introducing new test suites into Evergreen because it tends to result in their team expending the effort to stabilize it. Could you please clarify why this ticket was moved from the Sharding team? E.g. is there missing functionality to properly mix the sharding_continuous_config_stepdown.yml and sharding_last_stable_mongos_and_mixed_shards.yml behaviors?

Comment by Esha Maharishi (Inactive) [ 30/Jun/16 ]

Hmm, since some of the compatibility stuff relies on the config server responding asynchronously to commands sent by mongos, mainly that we don't get weird inconsistencies if the config primary goes down.

Comment by Kaloian Manassiev [ 30/Jun/16 ]

What kind of coverage are you hoping to get out of this test configuration, which we don't have when running with the latest mongos?

Generated at Thu Feb 08 04:07:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.