[SERVER-30440] Create featureCompatibilityVersion=3.4 jsCore passthrough Created: 31/Jul/17  Updated: 30/Oct/23  Resolved: 28/Nov/17

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure, Upgrade/Downgrade, Write Ops
Affects Version/s: None
Fix Version/s: 3.6.0-rc7

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Query 2017-12-04
Participants:

 Description   

It would be useful to have a jsCore passthrough that sets featureCompatibilityVersion=3.4 or even a featureCompatibilityVersion=3.4 variant.

One motivation is that our old update implementation is used when the featureCompatibilityVersion is 3.4, and our new system is used when the featureCompatibilityVersion is 3.6, so there is currently no integration test coverage for our old system. A jsCore passthrough with featureCompatibilityVersion=3.4 would be helpful, but it would also be good to run shard_key_immutable.js with featureCompatibilityVersion=3.4, and that test is not in the core suite.



 Comments   
Comment by Githook User [ 28/Nov/17 ]

Author:

{'name': 'Tess Avitabile', 'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com'}

Message: SERVER-30440 Create replica_sets_jscore_fcv34_passthrough
Branch: v3.6
https://github.com/mongodb/mongo/commit/924a4db540688e15dced5894a4bff6f943fc68ad

Comment by Tess Avitabile (Inactive) [ 21/Nov/17 ]

ramon.fernandez, this ticket adds a replica sets FCV 3.4 jscore passthrough to the 3.6 branch. This is important for test coverage of the old update system (when the FCV is 3.6, we use the new implementation of the update system), and to make sure that bugs that are fixed in the new update system on 3.6 are also fixed in the old update system. Would it be possible to push this during code freeze?

Comment by Tess Avitabile (Inactive) [ 21/Nov/17 ]

I realized we are already running shard_key_immutable.js under FCV 3.4 thanks to the sharding_last_stable_mongos_and_mixed_shards suite, so I will just do the FCV 3.4 jscore passthrough.

Comment by Max Hirschhorn [ 28/Sep/17 ]

tess.avitabile, it doesn't seem like there's a need for running existing tests with featureCompatibilityVersion=3.4 for other components so I think we should just add testing specifically for the old update codepath. I'd recommend defining a test suite similar to the following (based on replica_sets_jscore_passthrough.yml) that runs the "setFeatureCompatibilityVersion" command before each test and excludes any tests that are tagged with "requires_fcv36". (We'll of course need to go back through existing tests in the jstests/core/ directory and tag them with "requires_fcv36" appropriately.)

replica_sets_jscore_fcv34_passthrough.yml

selector:
  roots:
  - jstests/core/**/*.js
  exclude_files:
  # These tests are not expected to pass with replica-sets:
  - jstests/core/dbadmin.js
  - jstests/core/opcounters_write_cmd.js
  - jstests/core/read_after_optime.js
  - jstests/core/capped_update.js
  exclude_with_any_tags:
  - requires_fcv36
 
executor:
  config:
    shell_options:
      eval: >-
        testingReplication = true;
        assert.commandWorked(db.adminCommand({setFeatureCompatibilityVersion: '3.4'}));
      readMode: commands
  hooks:
  # The CheckReplDBHash hook waits until all operations have replicated to and have been applied
  # on the secondaries, so we run the ValidateCollections hook after it to ensure we're
  # validating the entire contents of the collection.
  - class: CheckReplOplogs
  - class: CheckReplDBHash
  - class: ValidateCollections
  - class: CleanEveryN
    n: 20
  fixture:
    class: ReplicaSetFixture
    mongod_options:
      oplogSize: 511
      set_parameters:
        enableTestCommands: 1
        numInitialSyncAttempts: 1
    num_nodes: 2

Names of new Evergreen tasks
  • replica_sets_jscore_fcv34_passthrough
  • replica_sets_jscore_fcv34_passthrough_WT

The new Evergreen tasks should be run on the following build variants to get coverage of all storage engines:

  • Enterprise RHEL 6.2
  • Enterprise RHEL 6.2 (inMemory)
  • Linux (ephemeralForTest)
  • Linux DEBUG
  • Windows 2008R2 DEBUG
  • SSL OS X 10.10
  • Ubuntu 14.04 (RocksDB)
  • ASAN Enterprise SSL Ubuntu 16.04 DEBUG
  • UBSAN Enterprise Ubuntu 16.04 DEBUG
  • Enterprise RHEL 6.2 DEBUG Code Coverage

A jsCore passthrough with featureCompatibilityVersion=3.4 would be helpful, but it would also be good to run shard_key_immutable.js with featureCompatibilityVersion=3.4, and that test is not in the core suite.

I'd recommend using a similar strategy as to what the Replication team took in the changes from bcf3d94 as part of SERVER-28100 to have the shard_key_immutable.js test logic itself live in jstests/libs/ and expose an option to run it once with featureCompatibilityVersion=3.4 and again with featureCompatibilityVersion=3.6.

Comment by Tess Avitabile (Inactive) [ 01/Aug/17 ]

That is true, but we do not get mixed version replica sets from that passthrough, correct?

Comment by Max Hirschhorn [ 01/Aug/17 ]

I also wonder if it would be helpful to have mixed-version clusters in this passthrough, where some nodes are version 3.6 and fCV=3.4, an some nodes are version 3.4. That would make this a true multiversion passthrough.

tess.avitabile, I think we get some of that right now through the existing sharding_last_stable_mongos_and_mixed_shards.yml test suite.

Comment by Tess Avitabile (Inactive) [ 01/Aug/17 ]

I also wonder if it would be helpful to have mixed-version clusters in this passthrough, where some nodes are version 3.6 and fCV=3.4, an some nodes are version 3.4. That would make this a true multiversion passthrough.

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