[SERVER-58052] Create separate variant for commit queue Created: 24/Jun/21  Updated: 20/Jul/21  Resolved: 20/Jul/21

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: Robert Guo (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-57852 Create separate variant for commit queue Closed
Sprint: STM 2021-07-12, STM 2021-07-26
Participants:
Story Points: 0

 Description   

Create a separate variant for CQ so we can leverage a separate pool of hosts to improve CQ's SLA.

The code is the following; as well ass adding the "lint" tag to all the relevant lint functions

diff --git a/etc/evergreen.yml b/etc/evergreen.yml
index c5dd5283bb..9702df4ad7 100644
--- a/etc/evergreen.yml
+++ b/etc/evergreen.yml
@@ -9139,6 +9139,25 @@ buildvariants:
     distros:
       - rhel80-xlarge+- <<: *enterprise-rhel-80-64-bit-dynamic-required-template
+  name: enterprise-rhel-80-64-bit-dynamic-required-commit-queue
+  display_name: "~ Shared Library Enterprise RHEL 8.0 Commit Queue"
+  batchtime: 999999999
+  run_on:
+    - rhel80-other-pool
+  tasks:
+    - name: compile_test_and_package_parallel_core_stream_TG
+    - name: compile_test_and_package_parallel_unittest_stream_with_recording_TG
+    - name: compile_test_and_package_parallel_unittest_stream_TG
+    - name: compile_test_and_package_parallel_dbtest_stream_TG
+    - name: jsCore
+    - name: .lint
+      distros:
+        - rhel80-small
+    - name: test_api_version_compatibility
+      distros:
+        - rhel80-small
+
 - &enterprise-rhel-80-64-bit-dynamic-all-feature-flags-required-template
   name: enterprise-rhel-80-64-bit-dynamic-all-feature-flags-required
   display_name: "! Shared Library Enterprise RHEL 8.0 (all feature flags)"

Also create a similar variant for all Query patch builds since the new Query variants aren't running non-JS tasks.
 



 Comments   
Comment by Robert Guo (Inactive) [ 20/Jul/21 ]

Moving convo to SERVER-57852

Comment by Andrew Morrow (Inactive) [ 29/Jun/21 ]

brian.mccarthy - That's good news, but I still have some reservations about this. We used to have a dedicated builder for the commit queue, and we then put a good amount of effort into making it just reuse tasks out of the existing required RHEL 8 dynamic builder. There were a few good reasons to do so:

  • Adding and removing tasks from the commit queue did not require a commit to the repo, since those tasks were always available from the basic RHEL 8 builder. Now, adding a task to the commit queue will first require adding the task to the new builder. We could somewhat mitigate this by importing the whole list of tasks from the other builder, but we may not be able to do that because of task specific variant assignments.
  • The buildvariant on which patch builds were run became the same as the buildvariant where the commit queue runs. If we make this change, that will no longer be true. Will we require people to also patch build on the new builder? If so, that would undermine your prioritization goals. If not, then a pass in your patch build doesn't quite convey the same assurances that it will pass in the commit queue.

I really think it is worth spending a little more time thinking about this before moving forward with the approach of adding a new buildvariant. I think having the commit queue tasks be a strict subset of a standard required builder is important. Could we just give commit queue tasks a priority bump? Could we introduce the idea of named/reserved pools within a variant?

Comment by Robert Guo (Inactive) [ 29/Jun/21 ]

That's great to hear Brian. Will pull this ticket into an earlier sprint in that case.

Comment by Robert Guo (Inactive) [ 28/Jun/21 ]

Sweet. Thanks for the explanation Drew!

Comment by Robert Guo (Inactive) [ 24/Jun/21 ]

acm Thank you for the info. We do absolutely want this builder to use the shared SCons cache. Is there something we can do to make happen? If you could point me to someone to talk to or some code that would be relevant, I would like to understand the limitation (or decision) further. For some background info on this ticket, the commit queue currently may get stuck indefinitely if we share the same pool of hosts, which I hope you'll agree, is scary and not an acceptable experience for a critical service all MongoDB developers rely on. (Although, admittedly, the real-world impact is nowhere near as substantial as not using SCons cache).

Comment by Robert Guo (Inactive) [ 24/Jun/21 ]

We should let DAG know to update the commit queue alias once this ticket goes in.

Generated at Thu Feb 08 05:43:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.