[SERVER-29332] Call setFeatureCompatibilityVersion once instead of for each database Created: 08/May/17  Updated: 30/May/17  Resolved: 30/May/17

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

Type: Task Priority: Major - P3
Reporter: Robert Guo (Inactive) Assignee: DO NOT USE - Backlog - Test Infrastructure Group (TIG)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:
Linked BF Score: 0

 Description   

Setting the featureCompatibilityVersion to 3.4 requires updating a document and creating an index. Setting the featureCompatibilityVersion to 3.2 requires updating a document and dropping that index. The validate_collections.js hook sets the featureCompatibilityVersion to 3.4 for each collection when running the fuzzer. This causes additional I/O load on the machine and can lead to the test being considered as having timed out. We should instead change to set the featureCompatibilityVersion to 3.4 once while validating all collections on the server before setting it back to 3.2.



 Comments   
Comment by Max Hirschhorn [ 30/May/17 ]

We'll just remove setting the featureCompatibilityVersion to 3.2 as part of SERVER-29350.

Comment by Max Hirschhorn [ 25/May/17 ]

Max, if it's alright, I'll add you as a reviewer to ensure I haven't missed anything featureCompatibilityVersion-related in the test infrastructure.

Thanks tess.avitabile, that sounds good to me.

Comment by Tess Avitabile (Inactive) [ 25/May/17 ]

Yes, since SERVER-29350 removes the ability to set the featureCompatibilityVersion to 3.2, I will be removing all tests that set the featureCompatibilityVersion to 3.2, so setting the featureCompatibilityVersion in jstests/hooks/validate_collections.js is unnecessary, so I can remove it as part of that work. Max, if it's alright, I'll add you as a reviewer to ensure I haven't missed anything featureCompatibilityVersion-related in the test infrastructure.

Comment by Max Hirschhorn [ 25/May/17 ]

tess.avitabile, if SERVER-29350 is going to remove the ability to set the featureCompatibilityVersion to 3.2, does that mean your work on the ticket will also remove setting the featureCompatibilityVersion from jstests/hooks/validate_collections.js? I'd rather not invest the time to change how we handle setting the featureCompatibilityVersion when validating collections if we're just going to delete that code anyway.

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