Skip to content

USHIFT-6639: Introduce test dynamic scheduling#6371

Draft
pacevedom wants to merge 24 commits intoopenshift:mainfrom
pacevedom:USHIFT-6639
Draft

USHIFT-6639: Introduce test dynamic scheduling#6371
pacevedom wants to merge 24 commits intoopenshift:mainfrom
pacevedom:USHIFT-6639

Conversation

@pacevedom
Copy link
Contributor

No description provided.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 18, 2026
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 18, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Mar 18, 2026

@pacevedom: This pull request references USHIFT-6639 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 18, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@coderabbitai
Copy link

coderabbitai bot commented Mar 18, 2026

Important

Review skipped

Auto reviews are limited based on label configuration.

🚫 Excluded labels (none allowed) (1)
  • do-not-merge/work-in-progress

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 8407cbb6-d43a-41dc-9d9d-15681ad78a50

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Walkthrough

Introduces a comprehensive dynamic VM scheduler system for parallel scenario testing. Core infrastructure adds scheduler integration, resource management, VM reuse capabilities, and detailed status reporting. Multiple scenario scripts are updated or created to declare dynamic scheduling requirements via standardized dynamic_schedule_requirements() functions.

Changes

Cohort / File(s) Summary
VM Scheduler Core
test/bin/vm_scheduler.sh
New 1500+ line scheduler implementing parallel VM orchestration: resource discovery, static/dynamic scenario classification, VM lifecycle management, reusability scoring, queue-based dispatch, timeout handling, and comprehensive status reporting with metrics.
Bootstrap Integration
test/bin/ci_phase_boot_and_test.sh
Bifurcates execution: adds SCHEDULER_ENABLED gate (default true) routing to new scheduler path, or legacy GNU parallel path. Exports host resource constants (HOST_TOTAL_VCPUS, HOST_TOTAL_MEMORY, SYSTEM_RESERVED_*) for scheduler planning.
Scenario Framework
test/bin/scenario.sh
Adds scheduler reuse hooks: get_scheduler_assigned_vm(), should_reuse_vm(), setup_vm_properties_from_existing(). Interlaces reuse checks in VM launch/removal flows with force_destroy flag support and virt-install retry tracking.
EL98 Bootc Scenarios
test/scenarios-bootc/presubmits/el98-src@* (45 files)
Adds dynamic_schedule_requirements() to all el98-bootc scenarios with resource/network specs. New scenarios include cert-manager, gateway-api, generic-device-plugin, multus, observability, sriov with aarch64-aware network handling. Some scenarios consolidate test paths (e.g., suites/standard1/dns.robot vs directory).
EL96 Microshift Scenarios
test/scenarios/presubmits/el96-src@* (16 files)
Introduces 16 new el96-src presubmit scenarios with consistent dynamic_schedule_requirements() declarations, VM lifecycle functions, and SYNC_FREQUENCY=5s for faster pre-submit runs.
EL98 Microshift Scenarios
test/scenarios/presubmits/el98-src@* (16 files)
Adds dynamic_schedule_requirements() to existing el98 scenarios; updates test paths in configuration, router, standard-suite1/2, storage. Includes disabled variants (e.g., upgrade-fails.sh.disabled).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
📝 Coding Plan
  • Generate coding plan for human review comments

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 18, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pacevedom

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 18, 2026
@pacevedom
Copy link
Contributor Author

@coderabbitai review

@coderabbitai
Copy link

coderabbitai bot commented Mar 18, 2026

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

Note

Due to the large number of review comments, Critical severity comments were prioritized as inline comments.

🟠 Major comments (30)
test/scenarios-bootc/presubmits/el98-src@version.sh-34-100 (1)

34-100: ⚠️ Potential issue | 🟠 Major

Remove duplicated function blocks; later definitions shadow earlier ones

The file contains three identical copies of all scenario functions (lines 6–32, 39–65, 72–98). In Bash, only the last definition is used at runtime, making the first two blocks dead code. Keep one copy per file, or split into separate scenario files if multiple test variants are intended.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@version.sh around lines 34 - 100,
The file contains repeated definitions of dynamic_schedule_requirements,
scenario_create_vms, scenario_remove_vms, and scenario_run_tests (functions like
dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms,
scenario_run_tests, and helper calls prepare_kickstart, launch_vm, remove_vm,
run_tests), so remove the duplicate function blocks and keep a single canonical
copy; decide which variant you want (e.g., whether to include fast=true and
which test suite: suites/standard1/dns.robot vs suites/standard1/version.robot)
and delete the other copies so only one set of these functions remains in the
script.
test/scenarios-bootc/presubmits/el98-src@etcd.sh-1-99 (1)

1-99: ⚠️ Potential issue | 🟠 Major

Remove duplicate function definitions; Bash silently uses only the final block.

dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms, and scenario_run_tests are each defined three times (at lines 6, 39, 72; 17, 50, 83; 22, 55, 88; and 26, 59, 92 respectively). Only the final definitions execute; the earlier DNS-targeting blocks are dead code. Maintain a single function set (the etcd variant) to eliminate maintenance risk and prevent silent misconfiguration.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@etcd.sh around lines 1 - 99, This
file contains three repeated definitions of dynamic_schedule_requirements,
scenario_create_vms, scenario_remove_vms, and scenario_run_tests; keep only one
copy (the etcd variant that calls suites/standard1/etcd.robot) and delete the
other duplicate blocks so the script has a single set of those functions (refer
to dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms,
scenario_run_tests and ensure scenario_run_tests invokes
suites/standard1/etcd.robot with the same --variable flags).
test/scenarios-bootc/presubmits/el98-src@multi-nic.sh-11-11 (1)

11-11: ⚠️ Potential issue | 🟠 Major

Fail fast when VM_MULTUS_NETWORK is unset

Line 11 emits scheduler constraints using ${VM_MULTUS_NETWORK} without validation. If empty, it can produce invalid network requirements and cause avoidable scheduling/test failures.

Suggested fix
 dynamic_schedule_requirements() {
+    : "${VM_MULTUS_NETWORK:?VM_MULTUS_NETWORK must be set for multi-nic scenario}"
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=default,"${VM_MULTUS_NETWORK}"
 boot_image=rhel98-bootc-source
 fips=false
 slow=true
 EOF
 }

As per coding guidelines, "Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@multi-nic.sh at line 11, The
networks assignment uses ${VM_MULTUS_NETWORK} without validation which will
produce invalid scheduler constraints if unset; update the script around the
networks variable assignment to check that VM_MULTUS_NETWORK is defined and
non-empty (e.g., test -n "$VM_MULTUS_NETWORK") and if not, print a clear error
and exit non‑zero so the job fails fast; alternatively build networks
conditionally (only append ,"$VM_MULTUS_NETWORK" when it is set) so the networks
variable is always valid.
test/scenarios-bootc/presubmits/el98-src@hostname.sh-34-99 (1)

34-99: ⚠️ Potential issue | 🟠 Major

Remove duplicate scenario definitions; only the last block runs

Lines 34–99 contain three identical copies of the scenario functions. In Bash, later definitions override earlier ones, so the first two test blocks (dns.robot runs) are dead code and only the final hostname.robot block executes. Consolidate to a single scenario definition or split into separate files.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@hostname.sh around lines 34 - 99,
The file contains three duplicate scenario definitions
(dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms,
scenario_run_tests) so remove the redundant earlier copies and keep a single
canonical block (keeping the initial shebang and only one set of functions:
dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms,
scenario_run_tests). Ensure scenario_run_tests calls the intended test suite
(switch the run_tests suite argument to either suites/standard1/hostname.robot
or suites/standard1/dns.robot as required) and retain calls to prepare_kickstart
and launch_vm in scenario_create_vms.
test/scenarios-bootc/presubmits/el98-src@networking-smoke.sh-34-99 (1)

34-99: ⚠️ Potential issue | 🟠 Major

Remove duplicate function blocks; only the last definitions are effective.

From Line 34 onward, the same four functions are redefined twice. In Bash, later definitions override earlier ones, so the first two blocks become dead code and can hide intent (e.g., dns.robot vs networking-smoke.robot).

Proposed cleanup (keep one canonical block)
@@
 scenario_run_tests() {
@@
-        suites/standard1/dns.robot
-}
-#!/bin/bash
-
-# Sourced from scenario.sh and uses functions defined there.
-
-# Opt-in to dynamic VM scheduling by declaring requirements
-dynamic_schedule_requirements() {
-    cat <<EOF
-min_vcpus=2
-min_memory=4096
-min_disksize=20
-networks=default
-boot_image=rhel98-bootc-source
-fips=false
-EOF
-}
-
-scenario_create_vms() {
-    prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
-    launch_vm --boot_blueprint rhel98-bootc
-}
-
-scenario_remove_vms() {
-    remove_vm host1
-}
-
-scenario_run_tests() {
-    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
-    run_tests host1 \
-        --variable "EXPECTED_OS_VERSION:9.8" \
-        --variable "SYNC_FREQUENCY:5s" \
-        suites/standard1/dns.robot
-}
-#!/bin/bash
-
-# Sourced from scenario.sh and uses functions defined there.
-
-# Opt-in to dynamic VM scheduling by declaring requirements
-dynamic_schedule_requirements() {
-    cat <<EOF
-min_vcpus=2
-min_memory=4096
-min_disksize=20
-networks=default
-boot_image=rhel98-bootc-source
-fips=false
-EOF
-}
-
-scenario_create_vms() {
-    prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
-    launch_vm --boot_blueprint rhel98-bootc
-}
-
-scenario_remove_vms() {
-    remove_vm host1
-}
-
-scenario_run_tests() {
-    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
-    run_tests host1 \
-        --variable "EXPECTED_OS_VERSION:9.8" \
-        --variable "SYNC_FREQUENCY:5s" \
         suites/standard1/networking-smoke.robot
 }

As per coding guidelines, "Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@networking-smoke.sh around lines 34
- 99, The file contains duplicate definitions of dynamic_schedule_requirements,
scenario_create_vms, scenario_remove_vms and scenario_run_tests (the first set
is dead code); remove the earlier duplicate block so only one canonical set of
these functions remains (ensure the kept scenario_run_tests uses
suites/standard1/networking-smoke.robot and the
prepare_kickstart/launch_vm/remove_vm calls remain unchanged in
scenario_create_vms/scenario_remove_vms).
test/scenarios/presubmits/el98-src@dual-stack.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Boot image mismatch.

boot_image=rhel-9.6-microshift-source vs prepare_kickstart ... rhel-9.8-microshift-source.

Also applies to: 18-18

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@dual-stack.sh at line 12, The boot image
variable boot_image is set to rhel-9.6-microshift-source but prepare_kickstart
is using rhel-9.8-microshift-source, causing a version mismatch; update
boot_image to rhel-9.8-microshift-source (and any other occurrences noted at the
other match) so it matches the prepare_kickstart invocation, ensuring the
variable name boot_image and the prepare_kickstart call use the same
rhel-9.8-microshift-source value.
test/scenarios/presubmits/el98-src@ipv6.sh-20-20 (1)

20-20: ⚠️ Potential issue | 🟠 Major

Boot image mismatch.

boot_image=rhel-9.6-microshift-source vs prepare_kickstart ... rhel-9.8-microshift-source.

Also applies to: 27-27

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@ipv6.sh at line 20, The boot image
variable boot_image is set to rhel-9.6-microshift-source but the
prepare_kickstart invocation expects rhel-9.8-microshift-source; update the
boot_image value (and any other occurrences of the 9.6 string) to
rhel-9.8-microshift-source so the variable and prepare_kickstart call match
(search for boot_image and prepare_kickstart in the script to find all places to
change).
test/scenarios/presubmits/el98-src@storage.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Boot image mismatch between scheduler requirements and VM creation.

dynamic_schedule_requirements declares rhel-9.6-microshift-source but prepare_kickstart uses rhel-9.8-microshift-source. This inconsistency may cause incorrect VM provisioning or failed reuse when the scheduler is enabled.

Also applies to: 18-18

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@storage.sh at line 12, The boot image
string is inconsistent: dynamic_schedule_requirements sets
"rhel-9.6-microshift-source" while prepare_kickstart (and the duplicate at the
other occurrence) uses "rhel-9.8-microshift-source"; update either
dynamic_schedule_requirements or prepare_kickstart so both use the exact same
boot_image value (and make the same change at the second occurrence) to ensure
scheduler requirements and VM creation match (refer to
dynamic_schedule_requirements and prepare_kickstart).
test/scenarios/presubmits/el98-src@router.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Boot image mismatch.

boot_image=rhel-9.6-microshift-source vs prepare_kickstart ... rhel-9.8-microshift-source.

Also applies to: 19-19

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@router.sh at line 12, The boot image
value for the boot_image variable is inconsistent with the value used in
prepare_kickstart (rhel-9.8-microshift-source); update boot_image to
rhel-9.8-microshift-source wherever it appears (e.g., the boot_image assignment
and the other occurrence mentioned) so prepare_kickstart and boot_image use the
same image string.
test/scenarios/presubmits/el98-src@standard-suite2.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Boot image mismatch.

boot_image=rhel-9.6-microshift-source vs prepare_kickstart ... rhel-9.8-microshift-source.

Also applies to: 18-18

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@standard-suite2.sh at line 12, The boot
image variable boot_image is set to rhel-9.6-microshift-source while
prepare_kickstart calls/use expects rhel-9.8-microshift-source; update the
boot_image assignment (or the prepare_kickstart invocation) so both use the same
RHEL version (e.g., change boot_image to rhel-9.8-microshift-source) and ensure
the same change is applied wherever boot_image is referenced (also adjust the
duplicate occurrence noted at the other location).
test/scenarios/presubmits/el98-src@backups.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Boot image mismatch.

boot_image=rhel-9.6-microshift-source vs prepare_kickstart ... rhel-9.8-microshift-source.

Also applies to: 18-18

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@backups.sh at line 12, The boot image
variable boot_image is set to rhel-9.6-microshift-source but the
prepare_kickstart invocation uses rhel-9.8-microshift-source, causing a version
mismatch; update boot_image (or the prepare_kickstart argument) so both use the
same image string (e.g., change boot_image to rhel-9.8-microshift-source) and
make the same change at the other occurrence referenced (line with the similar
mismatch) to keep both places consistent.
test/scenarios/presubmits/el98-src@upgrade-fails.sh.disabled-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

boot_image version mismatch with scenario_create_vms.

Same issue: boot_image=rhel-9.6-microshift-source doesn't match the rhel-9.8-microshift-source used in scenario_create_vms (line 25).

Proposed fix
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@upgrade-fails.sh.disabled at line 12, The
boot_image variable value in this file is inconsistent with scenario_create_vms;
update the boot_image assignment (boot_image=rhel-9.6-microshift-source) to
match the image used by scenario_create_vms (rhel-9.8-microshift-source) so both
references use the same version; locate the boot_image variable and change its
value to rhel-9.8-microshift-source to resolve the mismatch.
test/scenarios-bootc/presubmits/el98-src@olm.sh-36-36 (1)

36-36: ⚠️ Potential issue | 🟠 Major

Undefined variable ${networks} - should be ${NETWORKS}.

The script defines NETWORKS (uppercase) at line 15-18, but launch_vm references ${networks} (lowercase). This will expand to empty unless set elsewhere.

Proposed fix
-    launch_vm rhel98-bootc --network "${networks}" --vm_disksize 25 --vm_vcpus 4
+    launch_vm rhel98-bootc --network "${NETWORKS}" --vm_disksize 25 --vm_vcpus 4
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@olm.sh at line 36, The launch_vm
call uses an undefined lowercase variable ${networks}; update the argument to
use the correctly defined uppercase variable ${NETWORKS} so the call launch_vm
rhel98-bootc --network "${NETWORKS}" --vm_disksize 25 --vm_vcpus 4 passes the
intended network(s); ensure any other references to networks in this script
consistently use ${NETWORKS} rather than ${networks}.
test/scenarios/presubmits/el98-src@downgrade-block.sh.disabled-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

boot_image version mismatch with scenario_create_vms.

boot_image=rhel-9.6-... doesn't match rhel-9.8-... in scenario_create_vms (line 18).

Proposed fix
-boot_image=rhel-9.6-microshift-source-fake-next-minor
+boot_image=rhel-9.8-microshift-source-fake-next-minor
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@downgrade-block.sh.disabled at line 12,
The boot_image variable value (boot_image) in this script is set to
rhel-9.6-microshift-source-fake-next-minor but scenario_create_vms expects
rhel-9.8-...; update the boot_image assignment to match the image used by
scenario_create_vms (e.g., change boot_image to
rhel-9.8-microshift-source-fake-next-minor) or modify the scenario_create_vms
reference to use rhel-9.6 if that was intended so both identifiers match; locate
the boot_image variable and the scenario_create_vms reference to make them
consistent.
test/scenarios/presubmits/el98-src@upgrade-fails-then-recovers.sh.disabled-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

boot_image version mismatch with scenario_create_vms.

dynamic_schedule_requirements declares boot_image=rhel-9.6-microshift-source but scenario_create_vms (line 18) uses rhel-9.8-microshift-source. This inconsistency may cause incorrect VM reuse decisions.

Proposed fix
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@upgrade-fails-then-recovers.sh.disabled
at line 12, The boot_image value is inconsistent between
dynamic_schedule_requirements and scenario_create_vms; update one to match the
other so VM reuse logic is correct (either change dynamic_schedule_requirements'
boot_image from "rhel-9.6-microshift-source" to "rhel-9.8-microshift-source" or
change scenario_create_vms to use "rhel-9.6-microshift-source"), making sure the
same literal is used in both dynamic_schedule_requirements and
scenario_create_vms.
test/scenarios/presubmits/el98-src@low-latency.sh.disabled-15-15 (1)

15-15: ⚠️ Potential issue | 🟠 Major

boot_image version mismatch with scenario_create_vms.

boot_image=rhel-9.6-microshift-source-tuned doesn't match rhel-9.8-microshift-source-tuned in scenario_create_vms (line 21).

Proposed fix
-boot_image=rhel-9.6-microshift-source-tuned
+boot_image=rhel-9.8-microshift-source-tuned
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@low-latency.sh.disabled at line 15, The
boot_image variable value is inconsistent with scenario_create_vms: update
boot_image (boot_image=rhel-9.6-microshift-source-tuned) to match the image used
by scenario_create_vms (rhel-9.8-microshift-source-tuned) so both references use
the same version; locate and change the boot_image assignment and verify
scenario_create_vms (the scenario_create_vms reference/name) remains
rhel-9.8-microshift-source-tuned to ensure consistency.
test/scenarios/presubmits/el98-src@backup-and-restore-on-reboot.sh-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

boot_image version mismatch with scenario_create_vms.

boot_image=rhel-9.6-microshift-source doesn't match rhel-9.8-microshift-source in scenario_create_vms (line 18).

Proposed fix
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@backup-and-restore-on-reboot.sh at line
12, The boot_image variable value (boot_image=rhel-9.6-microshift-source) is
inconsistent with the image used in scenario_create_vms
(rhel-9.8-microshift-source); update the boot_image assignment to
rhel-9.8-microshift-source so both the boot_image variable and the
scenario_create_vms reference the same image (or alternatively change
scenario_create_vms to match if 9.6 is intended) and ensure any other references
to boot_image in this script use the updated value.
test/scenarios-bootc/presubmits/el98-src@kustomize.sh-34-99 (1)

34-99: ⚠️ Potential issue | 🟠 Major

Remove duplicate script bodies; only the last definitions are active.

Line 34 and Line 67 start additional full copies. Bash keeps the last function definitions, so earlier blocks are dead code and hide test-target intent (dns.robot vs kustomize.robot).

Proposed cleanup (single canonical script body)
 #!/bin/bash
 
 # Sourced from scenario.sh and uses functions defined there.
 
 # Opt-in to dynamic VM scheduling by declaring requirements
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=default
 boot_image=rhel98-bootc-source
 fips=false
 EOF
 }
 
 scenario_create_vms() {
     prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
     launch_vm --boot_blueprint rhel98-bootc
 }
 
 scenario_remove_vms() {
     remove_vm host1
 }
 
 scenario_run_tests() {
     # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
+    # pre-submit scenario completion time.
     run_tests host1 \
         --variable "EXPECTED_OS_VERSION:9.8" \
         --variable "SYNC_FREQUENCY:5s" \
-        suites/standard1/dns.robot
-}
-#!/bin/bash
-
-# Sourced from scenario.sh and uses functions defined there.
-
-# Opt-in to dynamic VM scheduling by declaring requirements
-dynamic_schedule_requirements() {
-    cat <<EOF
-min_vcpus=2
-min_memory=4096
-min_disksize=20
-networks=default
-boot_image=rhel98-bootc-source
-fips=false
-EOF
-}
-
-scenario_create_vms() {
-    prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
-    launch_vm --boot_blueprint rhel98-bootc
-}
-
-scenario_remove_vms() {
-    remove_vm host1
-}
-
-scenario_run_tests() {
-    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
-    run_tests host1 \
-        --variable "EXPECTED_OS_VERSION:9.8" \
-        --variable "SYNC_FREQUENCY:5s" \
-        suites/standard1/dns.robot
-}
-#!/bin/bash
-
-# Sourced from scenario.sh and uses functions defined there.
-
-# Opt-in to dynamic VM scheduling by declaring requirements
-dynamic_schedule_requirements() {
-    cat <<EOF
-min_vcpus=2
-min_memory=4096
-min_disksize=20
-networks=default
-boot_image=rhel98-bootc-source
-fips=false
-EOF
-}
-
-scenario_create_vms() {
-    prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
-    launch_vm --boot_blueprint rhel98-bootc
-}
-
-scenario_remove_vms() {
-    remove_vm host1
-}
-
-scenario_run_tests() {
-    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
-    run_tests host1 \
-        --variable "EXPECTED_OS_VERSION:9.8" \
-        --variable "SYNC_FREQUENCY:5s" \
         suites/standard1/kustomize.robot
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@kustomize.sh around lines 34 - 99,
This file contains two identical script bodies; remove the first duplicated
block so only one canonical set of functions remains
(dynamic_schedule_requirements, scenario_create_vms, scenario_remove_vms,
scenario_run_tests), and ensure the retained scenario_run_tests calls the
intended test suite (replace dns.robot with kustomize.robot if the latter is the
target) so there are no dead/overwritten definitions hiding the correct
test-target intent.
test/scenarios/presubmits/el98-src@standard-suite1.sh-5-16 (1)

5-16: ⚠️ Potential issue | 🟠 Major

Align scheduler boot_image with the EL9.8 provisioning path.
Line 12 currently requests an EL9.6 image while this scenario boots EL9.8. Under dynamic scheduling, this can pick/reuse the wrong VM base.

Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=default
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
 fips=false
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@standard-suite1.sh around lines 5 - 16,
The dynamic_schedule_requirements function currently sets boot_image to
"rhel-9.6-microshift-source" which mismatches the scenario's EL9.8 provisioning
path; update the boot_image value in dynamic_schedule_requirements to
"rhel-9.8-microshift-source" (or the exact EL9.8 image name used by the
provisioning path) so scheduled VMs use the correct EL9.8 base image.
test/scenarios/presubmits/el98-src@multi-nic.sh-5-16 (1)

5-16: ⚠️ Potential issue | 🟠 Major

Fix boot_image mismatch in scheduler requirements.
Line 12 declares an EL9.6 source image, but scenario_create_vms() provisions EL9.8. This can route scheduler allocation/reuse to an incompatible VM image.

Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=default,"${VM_MULTUS_NETWORK}"
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
 fips=false
 slow=true
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@multi-nic.sh around lines 5 - 16, The
scheduler requirements in dynamic_schedule_requirements() declare boot_image as
rhel-9.6-microshift-source which conflicts with the EL9.8 image used when
provisioning in scenario_create_vms(); update the boot_image value in
dynamic_schedule_requirements() to match the provisioned image
(rhel-9.8-microshift-source) so scheduler allocation/reuse targets the correct
VM image.
test/scenarios/presubmits/el98-src@configuration.sh-5-16 (1)

5-16: ⚠️ Potential issue | 🟠 Major

Correct boot_image to EL9.8 for scheduler compatibility.
Line 12 currently advertises EL9.6, but this scenario provisions EL9.8. That mismatch can break VM reuse/selection in dynamic scheduling.

Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=
-boot_image=rhel-9.6-microshift-source
+boot_image=rhel-9.8-microshift-source
 fips=false
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@configuration.sh around lines 5 - 16, The
boot_image value in the dynamic_schedule_requirements() function is incorrect
(currently "rhel-9.6-microshift-source"); update the boot_image entry to
"rhel-9.8-microshift-source" so the dynamic scheduler's VM requirements match
the actual EL9.8 provisioning and allow proper VM reuse/selection.
test/scenarios/presubmits/el96-src@show-config.sh-12-19 (1)

12-19: ⚠️ Potential issue | 🟠 Major

Align boot_image requirements with VM creation image.

Line 12 declares EL9.6, but Lines 18-19 provision EL9.8. This can break scheduler matching/reuse and run tests on an unintended OS version.

Proposed fix
 scenario_create_vms() {
-    prepare_kickstart host1 kickstart.ks.template rhel-9.8-microshift-source
-    launch_vm rhel-9.8
+    prepare_kickstart host1 kickstart.ks.template rhel-9.6-microshift-source
+    launch_vm
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@show-config.sh around lines 12 - 19, The
boot_image variable currently set to rhel-9.6-microshift-source is inconsistent
with the VM provisioning in scenario_create_vms which calls prepare_kickstart
with rhel-9.8-microshift-source and launch_vm rhel-9.8; update boot_image to
rhel-9.8-microshift-source (or alternatively change the
prepare_kickstart/launch_vm calls to rhel-9.6) so the boot_image,
prepare_kickstart invocation, and launch_vm target all reference the same EL
version to avoid scheduler mismatches.
test/scenarios/presubmits/el96-src@reboot.sh-12-19 (1)

12-19: ⚠️ Potential issue | 🟠 Major

Fix OS version mismatch between scheduler requirements and VM provisioning.

Line 12 requests EL9.6, while Lines 18-19 create EL9.8 VMs. That mismatch undermines scheduler correctness and VM reuse assumptions.

Proposed fix
 scenario_create_vms() {
-    prepare_kickstart host1 kickstart.ks.template rhel-9.8-microshift-source
-    launch_vm rhel-9.8
+    prepare_kickstart host1 kickstart.ks.template rhel-9.6-microshift-source
+    launch_vm
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@reboot.sh around lines 12 - 19, The
boot_image is set to rhel-9.6-microshift-source but scenario_create_vms() calls
prepare_kickstart(..., rhel-9.8-microshift-source) and launch_vm rhel-9.8,
causing an OS-version mismatch; update scenario_create_vms() so
prepare_kickstart uses rhel-9.6-microshift-source and launch_vm is invoked with
rhel-9.6 to match boot_image and scheduler expectations (adjust the arguments in
the prepare_kickstart and launch_vm calls).
test/scenarios/presubmits/el96-src@dns.sh-6-20 (1)

6-20: ⚠️ Potential issue | 🟠 Major

Keep the scheduler metadata and VM/test version in sync.

dynamic_schedule_requirements() advertises an EL9.6 image, but the VM creation path and EXPECTED_OS_VERSION are 9.8. With reuse enabled, this can assign the wrong base image and fail the presubmit for the wrong reason.

Also applies to: 29-31

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@dns.sh around lines 6 - 20,
dynamic_schedule_requirements() is advertising
boot_image=rhel-9.6-microshift-source while scenario_create_vms()
(prepare_kickstart/launch_vm) and EXPECTED_OS_VERSION target 9.8, which can
cause wrong image reuse; update dynamic_schedule_requirements() to use
boot_image=rhel-9.8-microshift-source (and any other scheduler metadata at lines
29-31) and ensure EXPECTED_OS_VERSION and the prepare_kickstart/launch_vm
arguments are consistent with that same 9.8 image/version.
test/scenarios-bootc/presubmits/el98-src@sriov.sh-20-29 (1)

20-29: ⚠️ Potential issue | 🟠 Major

Advertise the full NIC layout here.

scenario_create_vms() requests ${NETWORKS}, but the scheduler only sees sriov. That under-specifies the VM on x86 and is wrong on aarch64, where SR-IOV is intentionally removed.

Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=4
 min_memory=4096
 min_disksize=25
-networks=sriov
+networks="${NETWORKS}"
 boot_image=rhel98-bootc-source-optionals
 fips=false
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@sriov.sh around lines 20 - 29, The
scheduler is only seeing "sriov" from dynamic_schedule_requirements() while
scenario_create_vms() uses ${NETWORKS}, so update
dynamic_schedule_requirements() to advertise the full NIC layout expected by
scenario_create_vms() (e.g., set networks=${NETWORKS} or expand to the exact
comma-separated NIC list used by scenario_create_vms()), and handle architecture
differences (keep SR-IOV on x86, omit it on aarch64) so the scheduler and
scenario_create_vms() receive the same network specification.
test/scenarios/presubmits/el96-src@log-scan.sh-6-14 (1)

6-14: ⚠️ Potential issue | 🟠 Major

Declare the default NIC in the scheduler requirements.

This scenario boots with the default network, but networks= advertises no NICs. The scheduler can then reuse an offline VM for a path that needs SSH and online tests.

Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
-networks=
+networks=default
 boot_image=rhel-9.6-microshift-source
 fips=false
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@log-scan.sh around lines 6 - 14, The
scheduler requirements function dynamic_schedule_requirements currently sets
networks= (advertising no NICs); change that line to advertise the default
network (e.g., networks=default or the appropriate default NIC name for your
environment) so the scenario requests a live NIC for SSH/online tests; update
the networks= line in dynamic_schedule_requirements to the correct default NIC
identifier.
test/bin/scenario.sh-912-916 (1)

912-916: ⚠️ Potential issue | 🟠 Major

Don't pass OK (reused) to record_junit.

record_junit() only treats exact OK as success. This value falls into the failure branch, so every successful reuse increments FAILURES and emits a failing install_vm testcase.

Suggested fix
         # Scheduler has assigned an existing VM for reuse
         if setup_vm_properties_from_existing "${vmname}" "${scheduler_vm}"; then
-            record_junit "${vmname}" "install_vm" "OK (reused)"
+            record_junit "${vmname}" "install_vm" "OK"
+            echo "Reused existing scheduler VM for ${vmname}"
             return 0
         else
             record_junit "${vmname}" "install_vm" "FAILED (reuse failed)"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/bin/scenario.sh` around lines 912 - 916, The test records a reused VM as
"OK (reused)", but record_junit() treats only the exact string "OK" as success,
causing false failures; update the success record in the reuse branch so the
call to record_junit uses "OK" (e.g., replace "OK (reused)" with "OK") after
setup_vm_properties_from_existing succeeds (keep vmname and the "install_vm"
testcase), and if you need to preserve the "reused" note, write that to a
separate log or comment rather than as the record_junit status.
test/bin/vm_scheduler.sh-839-846 (1)

839-846: ⚠️ Potential issue | 🟠 Major

VM_GREENBOOT_TIMEOUT leaks across reused-scenario recursion.

In recursive reuse flow, if scenario A sets this env var and scenario B doesn’t, B inherits A’s timeout unexpectedly.

Proposed fix
         custom_greenboot_timeout=$(get_req_value "${req_file}" "greenboot_timeout" "")
         if [ -n "${custom_greenboot_timeout}" ]; then
             export VM_GREENBOOT_TIMEOUT="${custom_greenboot_timeout}"
             log "Using custom greenboot timeout: ${custom_greenboot_timeout}s"
+        else
+            unset VM_GREENBOOT_TIMEOUT || true
         fi
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/bin/vm_scheduler.sh` around lines 839 - 846, The VM_GREENBOOT_TIMEOUT
environment variable can persist across recursive reused scenarios because you
only export it when custom_greenboot_timeout is set; to prevent leakage, after
reading custom_greenboot_timeout in the block that calls get_req_value (and uses
req_file, custom_greenboot_timeout, and log), explicitly unset or clear
VM_GREENBOOT_TIMEOUT when custom_greenboot_timeout is empty (e.g., use unset
VM_GREENBOOT_TIMEOUT or export VM_GREENBOOT_TIMEOUT=) so scenario B won’t
inherit a prior scenario A value.
test/bin/vm_scheduler.sh-236-243 (1)

236-243: ⚠️ Potential issue | 🟠 Major

Lock acquisition can hang forever on stale locks.

acquire_lock has no timeout/stale-lock handling. A crashed holder can block scheduler progress indefinitely.

Proposed fix
 acquire_lock() {
     local lock_name="$1"
     local lock_file="${LOCK_DIR}/${lock_name}.lock"
+    local timeout="${SCHEDULER_LOCK_TIMEOUT:-300}"
+    local waited=0

     while ! mkdir "${lock_file}" 2>/dev/null; do
         sleep 1
+        waited=$((waited + 1))
+        if [ "${waited}" -ge "${timeout}" ]; then
+            log "ERROR: Timed out acquiring lock ${lock_name} after ${timeout}s"
+            return 1
+        fi
     done
+    echo "$$" > "${lock_file}/owner_pid"
 }

 release_lock() {
     local lock_name="$1"
     local lock_file="${LOCK_DIR}/${lock_name}.lock"
+    rm -f "${lock_file}/owner_pid" 2>/dev/null || true
     rmdir "${lock_file}" 2>/dev/null || true
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/bin/vm_scheduler.sh` around lines 236 - 243, acquire_lock currently
blocks forever if a lock dir remains from a crashed process; update acquire_lock
to implement a timeout and stale-lock handling: attempt to create the lock
directory (lock_file derived from LOCK_DIR and lock_name) in a loop but track
elapsed time and give up after a configurable timeout, and when a lock exists
check its age (or a PID file written by the lock holder) and remove the lock if
it's older than a stale threshold or the PID is not running before retrying;
ensure you write the holder PID (or timestamp) into the lock directory when
acquiring and document the timeout/stale thresholds as variables so other code
using acquire_lock and any corresponding release_lock can interoperate.
test/bin/vm_scheduler.sh-214-217 (1)

214-217: ⚠️ Potential issue | 🟠 Major

Requirement extraction failures should fail scheduling, not continue.

If get_scenario_requirements fails, the scenario is still queued later with default values, which can produce wrong VM sizing/compatibility decisions.

Proposed fix
 calculate_max_dynamic_requirements() {
     local -a dynamic_scenarios=("$@")
+    local failures=0
@@
-        if ! get_scenario_requirements "${scenario_script}" "${req_file}"; then
-            log "WARNING: Failed to get requirements for ${scenario_name}"
+        if ! get_scenario_requirements "${scenario_script}" "${req_file}"; then
+            log "ERROR: Failed to get requirements for ${scenario_name}"
+            failures=$((failures + 1))
             continue
         fi
@@
     log "Max dynamic scenario: vcpus=${MAX_DYNAMIC_VCPUS}, memory=${MAX_DYNAMIC_MEMORY}MB"
+    [ "${failures}" -eq 0 ]
 }

Also handle the return in orchestrate when calling calculate_max_dynamic_requirements to abort early on failure.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/bin/vm_scheduler.sh` around lines 214 - 217, When
get_scenario_requirements fails in the scheduling loop, don't silently continue
with defaults — treat it as a fatal scheduling error: replace the current
"continue" behavior in the block that calls get_scenario_requirements
"${scenario_script}" "${req_file}" so the caller exits non-zero (or returns an
error status) and logs the failure; likewise update orchestrate to check the
return of calculate_max_dynamic_requirements and abort/return immediately on
failure instead of proceeding. Locate the calls to get_scenario_requirements and
calculate_max_dynamic_requirements and ensure both propagate non-zero failures
up (exit or return) so scheduling stops when requirement extraction or
max-dynamic calculation fails.
🟡 Minor comments (2)
test/scenarios-bootc/presubmits/el98-src@show-config.sh-14-14 (1)

14-14: ⚠️ Potential issue | 🟡 Minor

Typo: fats=true should likely be fast=true.

Proposed fix
-fats=true
+fast=true
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@show-config.sh at line 14, There's
a typo assigning the shell variable: change the incorrect variable name
`fats=true` to `fast=true` in the show-config script so the intended `fast` flag
is set; update the assignment in the file line where `fats=true` appears (look
for the `fats` variable in show-config.sh) to use `fast` instead.
test/scenarios-bootc/presubmits/el98-src@multus.sh-21-30 (1)

21-30: ⚠️ Potential issue | 🟡 Minor

networks requirement doesn't match actual VM network configuration.

dynamic_schedule_requirements() hardcodes networks=multus, but scenario_create_vms() uses the NETWORKS variable which may include sriov on non-aarch64. This could cause scheduler mismatches.

Compare with el98-src@observability.sh which correctly uses networks="${NETWORKS}".

🔧 Suggested fix
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
-networks=multus
+networks=${NETWORKS}
 boot_image=rhel98-bootc-source-optionals
 fips=false
 EOF
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@multus.sh around lines 21 - 30, The
dynamic_schedule_requirements() function hardcodes networks=multus which can
mismatch the actual VM network list built in scenario_create_vms() (via the
NETWORKS variable); update dynamic_schedule_requirements() to use the runtime
NETWORKS value (e.g., set networks="${NETWORKS}" or interpolate the NETWORKS
variable) so the scheduler requirements reflect the same networks used when
creating VMs, ensuring compatibility with sriov/non-aarch64 setups.
🧹 Nitpick comments (4)
test/scenarios-bootc/presubmits/el98-src@auto-recovery.sh (1)

5-16: Centralize boot image config to prevent scheduler/runtime drift.

Line 12 hardcodes boot_image=rhel98-bootc-source, while Line 19 separately hardcodes the same value. Keep this in one constant so scheduling constraints and VM creation cannot diverge.

Proposed refactor
+BOOT_IMAGE="rhel98-bootc-source"
+
 dynamic_schedule_requirements() {
     cat <<EOF
 min_vcpus=2
 min_memory=4096
 min_disksize=20
 networks=
-boot_image=rhel98-bootc-source
+boot_image=${BOOT_IMAGE}
 fips=false
 fast=true
 EOF
 }
 
 scenario_create_vms() {
-    prepare_kickstart host1 kickstart-bootc.ks.template rhel98-bootc-source
+    prepare_kickstart host1 kickstart-bootc.ks.template "${BOOT_IMAGE}"
     launch_vm rhel98-bootc
 }

As per coding guidelines, "Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios-bootc/presubmits/el98-src`@auto-recovery.sh around lines 5 -
16, The boot image value is duplicated and hardcoded; introduce a single
constant (e.g., BOOT_IMAGE) at the top of the script and replace the literal
"rhel98-bootc-source" inside dynamic_schedule_requirements (boot_image=...) and
the other hardcoded occurrence used for VM creation so both reference that
constant; ensure the constant is exported or visible to functions that need it
and update any references to use the new symbol instead of the literal.
test/scenarios/presubmits/el98-src@upgrade-fails.sh.disabled (1)

17-23: Excessive blank lines.

Seven consecutive blank lines between the function and scenario_create_vms. Consider trimming to one.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el98-src`@upgrade-fails.sh.disabled around lines 17
- 23, There are seven consecutive blank lines between the preceding function and
the scenario_create_vms declaration; remove the extra empty lines so there is a
single blank line separating the function and the scenario_create_vms definition
to improve readability and adhere to style guidelines. Ensure you update the
area around the function (the function name above the gap) and the
scenario_create_vms symbol so only one blank line remains.
test/scenarios/presubmits/el96-src@validate-certificate-rotation.sh (1)

26-33: Stale comment references DNS tests.

The comment mentions "DNS tests" but this scenario runs validate-certificate-rotation.robot.

📝 Suggested fix
 scenario_run_tests() {
-    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
-    # pre-submit scenario completion time in DNS tests.
+    # The SYNC_FREQUENCY is set to a shorter-than-default value to speed up
+    # pre-submit scenario completion time.
     run_tests host1 \
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@validate-certificate-rotation.sh around
lines 26 - 33, The comment above scenario_run_tests incorrectly mentions "DNS
tests" even though this scenario runs validate-certificate-rotation.robot;
update the comment to accurately describe why SYNC_FREQUENCY is shortened (e.g.,
"to speed up pre-submit scenario completion time in certificate rotation tests")
or remove the DNS reference, leaving the note about SYNC_FREQUENCY; ensure you
edit the comment near the scenario_run_tests function that sets SYNC_FREQUENCY
and references validate-certificate-rotation.robot so the comment matches the
test purpose.
test/scenarios/presubmits/el96-src@containers-policy.sh (1)

26-33: Stale comment references DNS tests.

Same copy-paste issue as other scenarios—comment mentions "DNS tests" but runs containers-policy.robot.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/scenarios/presubmits/el96-src`@containers-policy.sh around lines 26 -
33, The comment above scenario_run_tests incorrectly references "DNS tests" but
this function invokes run_tests for containers-policy.robot; update the comment
to accurately describe this scenario (e.g., mention containers-policy or
container policy tests) so it matches the invoked suite; edit the comment block
near scenario_run_tests and the run_tests invocation (referencing run_tests
host1, SYNC_FREQUENCY, EXPECTED_OS_VERSION, and
suites/standard1/containers-policy.robot) to reflect the correct test type.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 004a340e-5e2a-4c25-92f5-55a1285c2943

📥 Commits

Reviewing files that changed from the base of the PR and between 0027601 and 3aef000.

📒 Files selected for processing (77)
  • test/bin/ci_phase_boot_and_test.sh
  • test/bin/scenario.sh
  • test/bin/vm_scheduler.sh
  • test/scenarios-bootc/presubmits/el98-src@ai-model-serving-online.sh
  • test/scenarios-bootc/presubmits/el98-src@auto-recovery-extra.sh
  • test/scenarios-bootc/presubmits/el98-src@auto-recovery.sh
  • test/scenarios-bootc/presubmits/el98-src@backup-and-restore-on-reboot.sh
  • test/scenarios-bootc/presubmits/el98-src@backups.sh
  • test/scenarios-bootc/presubmits/el98-src@cert-manager.sh
  • test/scenarios-bootc/presubmits/el98-src@configuration.sh
  • test/scenarios-bootc/presubmits/el98-src@containers-policy.sh
  • test/scenarios-bootc/presubmits/el98-src@dns.sh
  • test/scenarios-bootc/presubmits/el98-src@downgrade-block.sh
  • test/scenarios-bootc/presubmits/el98-src@dual-stack.sh
  • test/scenarios-bootc/presubmits/el98-src@etcd.sh
  • test/scenarios-bootc/presubmits/el98-src@feature-gates.sh
  • test/scenarios-bootc/presubmits/el98-src@gateway-api.sh
  • test/scenarios-bootc/presubmits/el98-src@generic-device-plugin.sh
  • test/scenarios-bootc/presubmits/el98-src@healthchecks-disabled-service.sh
  • test/scenarios-bootc/presubmits/el98-src@hostname.sh
  • test/scenarios-bootc/presubmits/el98-src@ipv6.sh
  • test/scenarios-bootc/presubmits/el98-src@kustomize.sh
  • test/scenarios-bootc/presubmits/el98-src@log-scan.sh
  • test/scenarios-bootc/presubmits/el98-src@multi-nic.sh
  • test/scenarios-bootc/presubmits/el98-src@multus.sh
  • test/scenarios-bootc/presubmits/el98-src@networking-smoke.sh
  • test/scenarios-bootc/presubmits/el98-src@observability.sh
  • test/scenarios-bootc/presubmits/el98-src@olm.sh
  • test/scenarios-bootc/presubmits/el98-src@pvc-resize.sh
  • test/scenarios-bootc/presubmits/el98-src@reboot.sh
  • test/scenarios-bootc/presubmits/el98-src@router.sh
  • test/scenarios-bootc/presubmits/el98-src@show-config.sh
  • test/scenarios-bootc/presubmits/el98-src@snapshot.sh
  • test/scenarios-bootc/presubmits/el98-src@sriov.sh
  • test/scenarios-bootc/presubmits/el98-src@storage-version-migration.sh
  • test/scenarios-bootc/presubmits/el98-src@tls-configuration.sh
  • test/scenarios-bootc/presubmits/el98-src@upgrade-fails-then-recovers.sh.disabled
  • test/scenarios-bootc/presubmits/el98-src@upgrade-fails.sh
  • test/scenarios-bootc/presubmits/el98-src@validate-certificate-rotation.sh
  • test/scenarios-bootc/presubmits/el98-src@validate-custom-certificates.sh
  • test/scenarios-bootc/presubmits/el98-src@validate-selinux-policy.sh
  • test/scenarios-bootc/presubmits/el98-src@validate-service-account-ca-bundle.sh
  • test/scenarios-bootc/presubmits/el98-src@version.sh
  • test/scenarios/presubmits/el96-src@auto-recovery.sh
  • test/scenarios/presubmits/el96-src@containers-policy.sh
  • test/scenarios/presubmits/el96-src@dns.sh
  • test/scenarios/presubmits/el96-src@etcd.sh
  • test/scenarios/presubmits/el96-src@feature-gates.sh
  • test/scenarios/presubmits/el96-src@hostname.sh
  • test/scenarios/presubmits/el96-src@kustomize.sh
  • test/scenarios/presubmits/el96-src@log-scan.sh
  • test/scenarios/presubmits/el96-src@networking-smoke.sh
  • test/scenarios/presubmits/el96-src@pvc-resize.sh
  • test/scenarios/presubmits/el96-src@reboot.sh
  • test/scenarios/presubmits/el96-src@show-config.sh
  • test/scenarios/presubmits/el96-src@snapshot.sh
  • test/scenarios/presubmits/el96-src@storage-version-migration.sh
  • test/scenarios/presubmits/el96-src@tls-configuration.sh
  • test/scenarios/presubmits/el96-src@validate-certificate-rotation.sh
  • test/scenarios/presubmits/el96-src@validate-custom-certificates.sh
  • test/scenarios/presubmits/el96-src@validate-selinux-policy.sh
  • test/scenarios/presubmits/el96-src@validate-service-account-ca-bundle.sh
  • test/scenarios/presubmits/el96-src@version.sh
  • test/scenarios/presubmits/el98-src@backup-and-restore-on-reboot.sh
  • test/scenarios/presubmits/el98-src@backups.sh
  • test/scenarios/presubmits/el98-src@configuration.sh
  • test/scenarios/presubmits/el98-src@downgrade-block.sh.disabled
  • test/scenarios/presubmits/el98-src@dual-stack.sh
  • test/scenarios/presubmits/el98-src@ipv6.sh
  • test/scenarios/presubmits/el98-src@low-latency.sh.disabled
  • test/scenarios/presubmits/el98-src@multi-nic.sh
  • test/scenarios/presubmits/el98-src@router.sh
  • test/scenarios/presubmits/el98-src@standard-suite1.sh
  • test/scenarios/presubmits/el98-src@standard-suite2.sh
  • test/scenarios/presubmits/el98-src@storage.sh
  • test/scenarios/presubmits/el98-src@upgrade-fails-then-recovers.sh.disabled
  • test/scenarios/presubmits/el98-src@upgrade-fails.sh.disabled

@pacevedom
Copy link
Contributor Author

/test ?

@pacevedom
Copy link
Contributor Author

/test e2e-aws-tests-bootc

@pacevedom
Copy link
Contributor Author

/test e2e-aws-tests-bootc

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 18, 2026

@pacevedom: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-tests-bootc 1b09200 link true /test e2e-aws-tests-bootc

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants