Skip to content

USHIFT-6342: Merging scenarios#5798

Merged
openshift-merge-bot[bot] merged 1 commit intoopenshift:mainfrom
kasturinarra:local-4.21
Nov 26, 2025
Merged

USHIFT-6342: Merging scenarios#5798
openshift-merge-bot[bot] merged 1 commit intoopenshift:mainfrom
kasturinarra:local-4.21

Conversation

@kasturinarra
Copy link
Contributor

Merging scenarios to make sure hypervisor resources are not choked up during the execution.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Nov 24, 2025
@openshift-ci-robot
Copy link

@kasturinarra: This pull request explicitly references no jira issue.

Details

In response to this:

Merging scenarios to make sure hypervisor resources are not choked up during the execution.

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.

@kasturinarra kasturinarra marked this pull request as draft November 24, 2025 11:50
@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 Nov 24, 2025
@kasturinarra
Copy link
Contributor Author

/test e2e-aws-tests-bootc-arm

@openshift-ci openshift-ci bot requested review from eslutsky and pacevedom November 24, 2025 11:51
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 24, 2025
@kasturinarra kasturinarra marked this pull request as ready for review November 24, 2025 13:26
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 24, 2025
@openshift-ci openshift-ci bot requested review from copejon and jogeo November 24, 2025 13:26

scenario_run_tests() {
# Run lifecycle tests first (restart tests), then misc tests (config tests)
# This order ensures no interference between tests
Copy link
Contributor

Choose a reason for hiding this comment

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

why they must run in order? afaik, by default, RF execute them in random order every time

Copy link
Contributor

Choose a reason for hiding this comment

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

if you need to, you can add export TEST_RANDOMIZATION=none at the init of the scenario

Copy link
Contributor Author

@kasturinarra kasturinarra Nov 24, 2025

Choose a reason for hiding this comment

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

I thought they should , but looking at the code i see TEST_RANDOMIZATION="all" is the default setting in test/bin/scenario.sh which means Robot Framework will randomize test execution order. So looking at each suite i see they have proper setup and teardown, so i thin we are good here. I will remove these comments from the code.

scenario_run_tests() {
run_tests host1 suites/fault-tests
# Run fault-tests first (network outage tests), then greenboot (boot health tests)
# This order ensures no interference between tests
Copy link
Contributor

Choose a reason for hiding this comment

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

do these 2 also must run in order? if so, I think it's better to run fault-tests in the last position, because they may disrupt some things in the cluster

Copy link
Contributor Author

Choose a reason for hiding this comment

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

same comment as above.

Copy link
Contributor

Choose a reason for hiding this comment

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

do not forget to add export TEST_RANDOMIZATION=none if you want to ensure execution order

@kasturinarra kasturinarra changed the title NO-ISSUE: Merging scenarios USHIFT-6342: Merging scenarios Nov 24, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 24, 2025

@kasturinarra: This pull request references USHIFT-6342 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 task to target the "4.21.0" version, but no target version was set.

Details

In response to this:

Merging scenarios to make sure hypervisor resources are not choked up during the execution.

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.

@kasturinarra
Copy link
Contributor Author

/retest

@kasturinarra kasturinarra force-pushed the local-4.21 branch 2 times, most recently from fa38ed8 to 78b3d71 Compare November 24, 2025 17:54
@kasturinarra
Copy link
Contributor Author

/retest

@kasturinarra
Copy link
Contributor Author

/test e2e-aws-tests-bootc-arm

@kasturinarra
Copy link
Contributor Author

/test e2e-aws-tests-bootc-periodic

@kasturinarra
Copy link
Contributor Author

/test e2e-aws-tests-bootc-periodic-arm

@kasturinarra
Copy link
Contributor Author

/retest

@agullon
Copy link
Contributor

agullon commented Nov 25, 2025

From the latests executions on periodics jobs I can see el96-src@* scenarios takes to run:

  • el96-src@ai-model-serving-offline: 6:00 min
  • el96-src@fault-tests-and-greenboot: 16:43 min
  • el96-src@gitops: 25 seconds
  • el96-src@isolated-net: 7:23 min
  • el96-src@offline: 5:38 min
  • el96-src@osconfig-cleanup-data: 10:55 min
  • el96-src@osconfig-lifecycle-and-misc: 29:12 mins
    • Lifecycle: 19:11 min
    • Clusterid: 3:55 min
    • Systemd-Resolved: 6:06 min
  • el96-src@telemetry: 4:55 min
  • el96-src@upgrade-fails-cannot-backup: 2:45 min

So I suggest merging gitops + telemetry + Clusterid + Systemd-Resolved. They all take about 16 mins.
el96-src@osconfig-lifecycle-and-misc will take only about 19 mins
@kasturinarra wdyt?

@kasturinarra
Copy link
Contributor Author

From the latests executions on periodics jobs I can see el96-src@* scenarios takes to run:

  • el96-src@ai-model-serving-offline: 6:00 min

  • el96-src@fault-tests-and-greenboot: 16:43 min

  • el96-src@gitops: 25 seconds

  • el96-src@isolated-net: 7:23 min

  • el96-src@offline: 5:38 min

  • el96-src@osconfig-cleanup-data: 10:55 min

  • el96-src@osconfig-lifecycle-and-misc: 29:12 mins

    • Lifecycle: 19:11 min
    • Clusterid: 3:55 min
    • Systemd-Resolved: 6:06 min
  • el96-src@telemetry: 4:55 min

  • el96-src@upgrade-fails-cannot-backup: 2:45 min

So I suggest merging gitops + telemetry + Clusterid + Systemd-Resolved. They all take about 16 mins. el96-src@osconfig-lifecycle-and-misc will take only about 19 mins @kasturinarra wdyt?

will check in sometime and get back...

@agullon
Copy link
Contributor

agullon commented Nov 25, 2025

So I suggest merging gitops + telemetry + Clusterid + Systemd-Resolved. They all take about 16 mins.

@kasturinarra If you move these 4 test suites into 1 scenario, you should use rhel96-bootc-source-gitops bootc image in the scenario. Afaik, it'll work because it's based on rhel96-bootc-source bootc image.

@kasturinarra
Copy link
Contributor Author

/retest

Copy link
Contributor

Choose a reason for hiding this comment

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

You don't need to use rhel96-bootc-source-gitops image in this scenario, because you are not running gitops tests. You can just use rhel96-bootc-source.

# Sourced from scenario.sh and uses functions defined there.

# Disable test randomization to ensure systemd-resolved runs last
# (it reboots the host which would break SSH for subsequent tests)
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just added there for safety to make sure things do not go wrong as adding it there also does not cause any harm so..

@kasturinarra
Copy link
Contributor Author

/retest

@kasturinarra
Copy link
Contributor Author

/test e2e-aws-tests-bootc-periodic

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 26, 2025

@kasturinarra: all tests passed!

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.

@agullon
Copy link
Contributor

agullon commented Nov 26, 2025

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 26, 2025
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 26, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: agullon, kasturinarra

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:
  • OWNERS [agullon,kasturinarra]

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

@kasturinarra
Copy link
Contributor Author

/verified by CI

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Nov 26, 2025
@openshift-ci-robot
Copy link

@kasturinarra: This PR has been marked as verified by CI.

Details

In response to this:

/verified by CI

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-merge-bot openshift-merge-bot bot merged commit f419527 into openshift:main Nov 26, 2025
11 checks passed
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. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants