[SERVER-35002] Replace RollbackTest with RollbackTestDeluxe Created: 15/May/18  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kyle Suarez Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 1
Labels: gm-ack, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-33091 Create rollback tests that do all typ... Closed
is related to SERVER-35176 Create a rollback fuzzer suite with t... Closed
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Participants:

 Description   

We are creating a five-node double rollback test library named RollbackTestDeluxe in SERVER-33091, which will offer a strict superset of the functionality of the original RollbackTest. We should just replace the old RollbackTest with the newer one. This should happen in all of the regular integration tests, as well as the various rollback fuzzer suites.

The new rollback test should be a drop-in replacement for the old one, but tests that use it and specify a custom ReplSetTest will require manual refactoring. robert.guo mentioned that multiversion_rollback.js is one such test.



 Comments   
Comment by Gregory McKeon (Inactive) [ 22/May/18 ]

judah.schvimer to file a new ticket to add a rolllback fuzzer variant with 5 node RS.

Comment by Kyle Suarez [ 15/May/18 ]

william.schultz – I have no strong opinions; that sounds like a reasonable request. If the Repl Team goes that route, I would suggest converting this ticket into a task that allows RollbackTestDeluxe to subclass RollbackTest so that we can cut down the (many) lines of repeated code. (Or close this as Won't Fix and file a new ticket.)

Comment by William Schultz (Inactive) [ 15/May/18 ]

Are we sure we want to replace all instances of the old 3-node fixture with the new one? Debugging issues is certainly much easier in a 3-node set as opposed to a 5-node set. Perhaps we should consider creating an additional suite that utilizes the 5-node variant, in addition to keeping the existing suites in service.

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