action #176061
closed
[Containers] test fails in kubectl
Added by ggardet_arm 8 days ago.
Updated 1 day ago.
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-DVD-aarch64-container_host_kubectl@aarch64 fails in
kubectl
kernel 6.13 update removed some CGROUP config options:
- [1mCONFIG_CGROUP_CPUACCT[m: [1;31mmissing (fail)[m
- [1mCONFIG_CGROUP_DEVICE[m: [1;31mmissing (fail)[m
- [1mCONFIG_CGROUP_FREEZER[m: [1;31mmissing (fail)[m
Test suite description¶
Maintainer: dheidler. Extra tests about CLI software in container module
2023-08-10/dimstar: added QEMURAM=2048 (boo#1212824)
Reproducible¶
Fails since (at least) Build 20250122
Expected result¶
Last good: 20250121 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Description updated (diff)
Maybe @mkoutny would have more information?
- Tags set to containers, tumbleweed
- Subject changed from test fails in kubectl to [Containers] test fails in kubectl
- Status changed from New to Workable
- Priority changed from Normal to High
Good, good, this is exactly what I wanted to figure out by the disablement -- I disabled controllers that don't exist on the v2 hierarchy.
Given:
- [37mcgroup hierarchy[m: [32mcgroups V2 mounted, cpu|cpuset|memory controllers status: good[m
kubectl actually runs on v2 hierarchy, so it won't likely use any of those controllers and this is only a stale kernel config check.
Is this check part of kubectl itself or some of our distro install scripts? I think the check should be either moved to optional features (for legacy v1 users) or not checked at all. Maybe @RBrownSUSE knows more?
considering k3s is installed using timeout 180 curl -sfL https://get.k3s.io -o install_k3s.sh; echo vtznr-$?- this looks like upstream code
mkoutny wrote in #note-5:
kubectl actually runs on v2 hierarchy, so it won't likely use any of those controllers and this is only a stale kernel config check.
Is this check part of kubectl itself or some of our distro install scripts? I think the check should be either moved to optional features (for legacy v1 users) or not checked at all. Maybe @RBrownSUSE knows more?
It should be a shell script provided by k3s -> /var/lib/rancher/k3s/data/.../bin/check-config, thus should we file an issue for k3s?
- Project changed from openQA Tests (public) to Containers and images
- Category deleted (
Bugs in existing tests)
- Status changed from Workable to In Progress
- Assignee set to rbranco
- Status changed from In Progress to Resolved
Also available in: Atom
PDF