Repository navigation
test(e2e): support configurable Kata RuntimeClass - #4454
jiripetrlik wants to merge 1 commit into
Conversation
Bobbins228
left a comment
Bobbins228
left a comment
There was a problem hiding this comment.
The configurable RuntimeClass wiring looks correct. Please restore the RuntimeClass's prior admission label after e2e runs against an existing cluster; the inline comment explains the persistent cluster-wide effect.
| helm_extra_args+=(--set "server.telemetryEnabled=${OPENSHELL_TELEMETRY_ENABLED}") | ||
| helm_extra_args+=(--set supervisor.sandboxRuntime.networkPolicyEnforced=true) | ||
| if [ -n "${KATA_CONTAINERS_RUNTIME_CLASS:-}" ]; then | ||
| kctl label runtimeclass "${KATA_CONTAINERS_RUNTIME_CLASS}" \ |
There was a problem hiding this comment.
On an existing cluster (OPENSHELL_E2E_KUBE_CONTEXT), this overwrites a cluster-scoped admission label, but cleanup() never restores its previous value. Before the run, an unlabeled RuntimeClass (or one labeled false) is not approved for sandbox attachment. After the run, other OpenShell workspaces on that cluster can select it even though the test release is gone. Please record the previous label and restore it during cleanup, including when the run fails.
37a8884 to
d2a32d1
Compare
|
Thank you @Bobbins228 for your review. I've updated the PR, it should preserve old labels now. |
Bobbins228
left a comment
Bobbins228
left a comment
There was a problem hiding this comment.
The RuntimeClass label cleanup addresses my earlier request and restores the prior state on exit. The code changes look good to me. The reported Rust e2e failure and timeouts still need validation before merge.
|
This pull request has had no activity for 14 days and is now marked stale. |
github-actions
Bot
added
the
state:stale
Pass KATA_CONTAINERS_RUNTIME_CLASS to the Helm chart and label the selected RuntimeClass for sandbox resource admission. Signed-off-by: Jiri Petrlik <jpetrlik@redhat.com>
d2a32d1 to
575d735
Compare
github-actions
Bot
removed
the
state:stale
|
Thanks for putting this together and addressing the RuntimeClass label cleanup feedback. We are closing this PR as won't do for now. We are not actively testing Kata Containers in CI, so adding a Kata-specific configuration path to the existing E2E wrapper does not currently provide enough ongoing validation to justify maintaining it. Manual testing against a Kata-enabled cluster can use the existing Helm development workflow described in We can revisit this as part of a focused effort to establish reliable Kata testing in CI. That effort should identify suitable runner infrastructure and an owner, verify that workload pods actually use Kata, define the supported test coverage and concurrency, and demonstrate repeatable results with useful failure diagnostics. The failure and timeouts reported here would need to be resolved or explained with evidence as part of that work. The broader proposal in #4459 needs a concrete CI infrastructure plan and more specific, measurable acceptance criteria before we pursue implementation. Closing this PR does not rule out that future effort. |
Pass KATA_CONTAINERS_RUNTIME_CLASS to the Helm chart and label the selected RuntimeClass for sandbox resource admission.
Summary
Allow Kubernetes e2e runs to select a Kata RuntimeClass through KATA_CONTAINERS_RUNTIME_CLASS. Label the selected RuntimeClass for sandbox resource admission before installing OpenShell.
Related Issue
Changes
Testing
Bash syntax, ShellCheck, and git diff --check passed.
Ran Kubernetes e2e on Podman-backed Kind with kata-qemu and IMAGE_TAG=dev.
Confirmed RuntimeClass labeling and Kata workload execution.
All 6 CLI conformance scenarios passed.
Rust e2e results: 81 passed, 1 failed, 15 timed out, 3 skipped.
Kubernetes reported Kata sandbox creation errors:
"Creating watcher returned error too many open files".
The assertion failure concerned an SSH session failing to reattach.
[*] Checks appropriate to the affected code and behavior pass
Unit tests added/updated (not applicable)
E2E tests added/updated (harness updated; no new test cases
Checklist