QA » openQA Project » openQA Tests » Containers

I could identify 4 places where we use k3s:

• helm
• kubectl
• podman-pods
• run_container_in_k3s

kubectl and run_container_in_k3s is closely bound to k3s, there we cannot do much. podman-pods would be covered by podman-bats and there we could do something. helm is not relevant.

We are using k3s for testing some kubernetes-related packages and functionality (kubectl, podman kube apply) and are facing the problem that k3s removed s390x support in https://github.com/k3s-io/k3s/issues/8987. This means that we are unable to continue testing those features, unless k3s will continue to support s390x.

A quick survey revealed that only the kubectl utility and the podman kube apply functionality are being affected by this. Unless it is a goal to provide kubernetes support for s390x, we should stop testing those functions due to the lack of necessary auxiliary tooling, provided by k3s.

ph03nix wrote in #note-3:

We are using k3s for testing some kubernetes-related packages and functionality (kubectl, podman kube apply) and are facing the problem that k3s removed s390x support in https://github.com/k3s-io/k3s/issues/8987. This means that we are unable to continue testing those features, unless k3s will continue to support s390x.

A quick survey revealed that only the kubectl utility and the podman kube apply functionality are being affected by this. Unless it is a goal to provide kubernetes support for s390x, we should stop testing those functions due to the lack of necessary auxiliary tooling, provided by k3s.

We know of at least one paying customer who relies on kubernetes packages in SLES.

See also https://github.com/k3s-io/k3s/issues/9222

Poked Jose about the current status.