[release-5.0] USHIFT-6857: CI implementation: Support MicroShift V5.0 on RHEL 10.2 GA Implementation - #7298
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@agullon: This pull request references USHIFT-6857 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 "5.0.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. |
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
openshift-ci
Bot
added
the
approved
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
@agullon: /override requires failed status contexts, check run or a prowjob name to operate on.
Only the following failed contexts/checkruns were expected:
If you are trying to override a checkrun that has a space in it, you must put a double quote on the context. 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 kubernetes-sigs/prow repository. |
|
/test e2e-aws-tests-bootc-release-el9 |
|
/test ci/prow/e2e-aws-tests |
|
/test e2e-aws-tests |
81b7107 to
1d8557d
Compare
|
/test e2e-aws-tests-bootc-release-el9 /test e2e-aws-tests |
|
/override ci/prow/e2e-aws-tests-bootc-release-el9 because this has not change in this PR |
|
@agullon: Overrode contexts on behalf of agullon: ci/prow/e2e-aws-tests, ci/prow/e2e-aws-tests-bootc-release-arm-el9, ci/prow/e2e-aws-tests-bootc-release-el9 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 kubernetes-sigs/prow repository. |
|
/test e2e-aws-tests-bootc-release-el10 |
|
/test e2e-aws-tests-bootc-periodic-arm-el9 |
|
/override ci/prow/e2e-aws-tests-bootc-periodic-el10 because changes in this PR only affect el10 releases CI jobs |
|
@agullon: Overrode contexts on behalf of agullon: ci/prow/e2e-aws-tests-bootc-periodic-el10, ci/prow/e2e-aws-tests-periodic 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 kubernetes-sigs/prow repository. |
2e1389c to
8bc7cb8
Compare
|
/test e2e-aws-tests-cache |
|
/test e2e-aws-tests-bootc-periodic-arm-el9 |
|
/test e2e-aws-tests |
|
Scheduling tests matching the |
|
/test e2e-aws-tests-release |
|
/retest |
|
/override ci/prow/e2e-aws-tests-bootc-release-arm-el9 Overriding the release presubmit jobs. This PR only adds new upgrade
|
|
@agullon: Overrode contexts on behalf of agullon: ci/prow/e2e-aws-tests-bootc-release-arm-el10, ci/prow/e2e-aws-tests-bootc-release-arm-el9, ci/prow/e2e-aws-tests-bootc-release-el10, ci/prow/e2e-aws-tests-bootc-release-el9, ci/prow/e2e-aws-tests-release 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 kubernetes-sigs/prow repository. |
|
@agullon: The following tests 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. |
|
/label jira/valid-bug |
openshift-ci
Bot
added
jira/valid-bug
openshift-ci-robot
added
the
verified
|
@agullon: This PR has been marked as verified by 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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: agullon, 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 |
38e096d
into
openshift:release-5.0
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
openshift#7298 reduced release-scenario VM disks from 30GB to 20GB. That is safe for the lvms-standard/standard scenarios (they create a single 1Gi PVC), but the ginkgo scenario runs the full storage spec suite which requests several 1Gi PVCs concurrently. At 20GB the topolvm data VG only has ~420MiB free, so 7 storage specs fail with: ResourceExhausted ... no enough space left on VG: free=440401920, requested=1073741824 (arm-el10) and on x86 el10 the same undersized VM shows etcd ReadIndex latency and apiserver TLS-handshake flaps from I/O contention. Restore only this scenario to --vm_disksize 30; the other nine 20GB scenarios stay as-is since a single 1Gi PVC fits comfortably. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
3 participants
Summary
Backport of #7140 to
release-5.0.Test plan