USHIFT-6639: Introduce test dynamic scheduling#6371
USHIFT-6639: Introduce test dynamic scheduling#6371pacevedom wants to merge 24 commits intoopenshift:mainfrom
Conversation
Adjust fast tags for better scheduling
|
@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. DetailsIn 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. |
|
Skipping CI for Draft Pull Request. |
|
Important Review skippedAuto reviews are limited based on label configuration. 🚫 Excluded labels (none allowed) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughIntroduces 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 Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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. Comment |
|
[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 DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
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 | 🟠 MajorRemove 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 | 🟠 MajorRemove duplicate function definitions; Bash silently uses only the final block.
dynamic_schedule_requirements,scenario_create_vms,scenario_remove_vms, andscenario_run_testsare 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 | 🟠 MajorFail fast when
VM_MULTUS_NETWORKis unsetLine 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 | 🟠 MajorRemove 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 | 🟠 MajorRemove 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.robotvsnetworking-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 | 🟠 MajorBoot image mismatch.
boot_image=rhel-9.6-microshift-sourcevsprepare_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 | 🟠 MajorBoot image mismatch.
boot_image=rhel-9.6-microshift-sourcevsprepare_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 | 🟠 MajorBoot image mismatch between scheduler requirements and VM creation.
dynamic_schedule_requirementsdeclaresrhel-9.6-microshift-sourcebutprepare_kickstartusesrhel-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 | 🟠 MajorBoot image mismatch.
boot_image=rhel-9.6-microshift-sourcevsprepare_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 | 🟠 MajorBoot image mismatch.
boot_image=rhel-9.6-microshift-sourcevsprepare_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 | 🟠 MajorBoot image mismatch.
boot_image=rhel-9.6-microshift-sourcevsprepare_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 | 🟠 Majorboot_image version mismatch with scenario_create_vms.
Same issue:
boot_image=rhel-9.6-microshift-sourcedoesn't match therhel-9.8-microshift-sourceused inscenario_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 | 🟠 MajorUndefined variable
${networks}- should be${NETWORKS}.The script defines
NETWORKS(uppercase) at line 15-18, butlaunch_vmreferences${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 | 🟠 Majorboot_image version mismatch with scenario_create_vms.
boot_image=rhel-9.6-...doesn't matchrhel-9.8-...inscenario_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 | 🟠 Majorboot_image version mismatch with scenario_create_vms.
dynamic_schedule_requirementsdeclaresboot_image=rhel-9.6-microshift-sourcebutscenario_create_vms(line 18) usesrhel-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 | 🟠 Majorboot_image version mismatch with scenario_create_vms.
boot_image=rhel-9.6-microshift-source-tuneddoesn't matchrhel-9.8-microshift-source-tunedinscenario_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 | 🟠 Majorboot_image version mismatch with scenario_create_vms.
boot_image=rhel-9.6-microshift-sourcedoesn't matchrhel-9.8-microshift-sourceinscenario_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 | 🟠 MajorRemove 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.robotvskustomize.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 | 🟠 MajorAlign scheduler
boot_imagewith 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 | 🟠 MajorFix
boot_imagemismatch in scheduler requirements.
Line 12 declares an EL9.6 source image, butscenario_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 | 🟠 MajorCorrect
boot_imageto 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 | 🟠 MajorAlign
boot_imagerequirements 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 | 🟠 MajorFix 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 | 🟠 MajorKeep the scheduler metadata and VM/test version in sync.
dynamic_schedule_requirements()advertises an EL9.6 image, but the VM creation path andEXPECTED_OS_VERSIONare 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 | 🟠 MajorAdvertise the full NIC layout here.
scenario_create_vms()requests${NETWORKS}, but the scheduler only seessriov. 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 | 🟠 MajorDeclare 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 | 🟠 MajorDon't pass
OK (reused)torecord_junit.
record_junit()only treats exactOKas success. This value falls into the failure branch, so every successful reuse incrementsFAILURESand emits a failinginstall_vmtestcase.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_TIMEOUTleaks 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 | 🟠 MajorLock acquisition can hang forever on stale locks.
acquire_lockhas 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 | 🟠 MajorRequirement extraction failures should fail scheduling, not continue.
If
get_scenario_requirementsfails, 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
orchestratewhen callingcalculate_max_dynamic_requirementsto 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 | 🟡 MinorTypo:
fats=trueshould likely befast=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
networksrequirement doesn't match actual VM network configuration.
dynamic_schedule_requirements()hardcodesnetworks=multus, butscenario_create_vms()uses theNETWORKSvariable which may includesriovon non-aarch64. This could cause scheduler mismatches.Compare with
el98-src@observability.shwhich correctly usesnetworks="${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
📒 Files selected for processing (77)
test/bin/ci_phase_boot_and_test.shtest/bin/scenario.shtest/bin/vm_scheduler.shtest/scenarios-bootc/presubmits/el98-src@ai-model-serving-online.shtest/scenarios-bootc/presubmits/el98-src@auto-recovery-extra.shtest/scenarios-bootc/presubmits/el98-src@auto-recovery.shtest/scenarios-bootc/presubmits/el98-src@backup-and-restore-on-reboot.shtest/scenarios-bootc/presubmits/el98-src@backups.shtest/scenarios-bootc/presubmits/el98-src@cert-manager.shtest/scenarios-bootc/presubmits/el98-src@configuration.shtest/scenarios-bootc/presubmits/el98-src@containers-policy.shtest/scenarios-bootc/presubmits/el98-src@dns.shtest/scenarios-bootc/presubmits/el98-src@downgrade-block.shtest/scenarios-bootc/presubmits/el98-src@dual-stack.shtest/scenarios-bootc/presubmits/el98-src@etcd.shtest/scenarios-bootc/presubmits/el98-src@feature-gates.shtest/scenarios-bootc/presubmits/el98-src@gateway-api.shtest/scenarios-bootc/presubmits/el98-src@generic-device-plugin.shtest/scenarios-bootc/presubmits/el98-src@healthchecks-disabled-service.shtest/scenarios-bootc/presubmits/el98-src@hostname.shtest/scenarios-bootc/presubmits/el98-src@ipv6.shtest/scenarios-bootc/presubmits/el98-src@kustomize.shtest/scenarios-bootc/presubmits/el98-src@log-scan.shtest/scenarios-bootc/presubmits/el98-src@multi-nic.shtest/scenarios-bootc/presubmits/el98-src@multus.shtest/scenarios-bootc/presubmits/el98-src@networking-smoke.shtest/scenarios-bootc/presubmits/el98-src@observability.shtest/scenarios-bootc/presubmits/el98-src@olm.shtest/scenarios-bootc/presubmits/el98-src@pvc-resize.shtest/scenarios-bootc/presubmits/el98-src@reboot.shtest/scenarios-bootc/presubmits/el98-src@router.shtest/scenarios-bootc/presubmits/el98-src@show-config.shtest/scenarios-bootc/presubmits/el98-src@snapshot.shtest/scenarios-bootc/presubmits/el98-src@sriov.shtest/scenarios-bootc/presubmits/el98-src@storage-version-migration.shtest/scenarios-bootc/presubmits/el98-src@tls-configuration.shtest/scenarios-bootc/presubmits/el98-src@upgrade-fails-then-recovers.sh.disabledtest/scenarios-bootc/presubmits/el98-src@upgrade-fails.shtest/scenarios-bootc/presubmits/el98-src@validate-certificate-rotation.shtest/scenarios-bootc/presubmits/el98-src@validate-custom-certificates.shtest/scenarios-bootc/presubmits/el98-src@validate-selinux-policy.shtest/scenarios-bootc/presubmits/el98-src@validate-service-account-ca-bundle.shtest/scenarios-bootc/presubmits/el98-src@version.shtest/scenarios/presubmits/el96-src@auto-recovery.shtest/scenarios/presubmits/el96-src@containers-policy.shtest/scenarios/presubmits/el96-src@dns.shtest/scenarios/presubmits/el96-src@etcd.shtest/scenarios/presubmits/el96-src@feature-gates.shtest/scenarios/presubmits/el96-src@hostname.shtest/scenarios/presubmits/el96-src@kustomize.shtest/scenarios/presubmits/el96-src@log-scan.shtest/scenarios/presubmits/el96-src@networking-smoke.shtest/scenarios/presubmits/el96-src@pvc-resize.shtest/scenarios/presubmits/el96-src@reboot.shtest/scenarios/presubmits/el96-src@show-config.shtest/scenarios/presubmits/el96-src@snapshot.shtest/scenarios/presubmits/el96-src@storage-version-migration.shtest/scenarios/presubmits/el96-src@tls-configuration.shtest/scenarios/presubmits/el96-src@validate-certificate-rotation.shtest/scenarios/presubmits/el96-src@validate-custom-certificates.shtest/scenarios/presubmits/el96-src@validate-selinux-policy.shtest/scenarios/presubmits/el96-src@validate-service-account-ca-bundle.shtest/scenarios/presubmits/el96-src@version.shtest/scenarios/presubmits/el98-src@backup-and-restore-on-reboot.shtest/scenarios/presubmits/el98-src@backups.shtest/scenarios/presubmits/el98-src@configuration.shtest/scenarios/presubmits/el98-src@downgrade-block.sh.disabledtest/scenarios/presubmits/el98-src@dual-stack.shtest/scenarios/presubmits/el98-src@ipv6.shtest/scenarios/presubmits/el98-src@low-latency.sh.disabledtest/scenarios/presubmits/el98-src@multi-nic.shtest/scenarios/presubmits/el98-src@router.shtest/scenarios/presubmits/el98-src@standard-suite1.shtest/scenarios/presubmits/el98-src@standard-suite2.shtest/scenarios/presubmits/el98-src@storage.shtest/scenarios/presubmits/el98-src@upgrade-fails-then-recovers.sh.disabledtest/scenarios/presubmits/el98-src@upgrade-fails.sh.disabled
test/scenarios-bootc/presubmits/el98-src@generic-device-plugin.sh
Outdated
Show resolved
Hide resolved
test/scenarios-bootc/presubmits/el98-src@healthchecks-disabled-service.sh
Outdated
Show resolved
Hide resolved
|
/test ? |
|
/test e2e-aws-tests-bootc |
|
/test e2e-aws-tests-bootc |
|
@pacevedom: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
No description provided.