Code change:
} /* <del> Release : v1.12 Testname: Security Context: runAsUser (id:65534) Description: Container created with runAsUser option, passing an id (id:65534) uses that given id when running the container. This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, runAsUser=65534 Description: Container is created with runAsUser option by passing uid 65534 to run as unpriviledged user. Pod MUST be in Succeeded phase. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support running as UID / GID. </ins> */ <del> It("should run the container with uid 65534 [LinuxOnly] [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should run the container with uid 65534 [LinuxOnly] [NodeConformance]", func() { </ins> createAndWaitUserPod(65534) }) /* <del> Release : v1.12 Testname: Security Context: runAsUser (id:0) Description: Container created with runAsUser option, passing an id (id:0) uses that given id when running the container. This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, runAsUser=0 Description: Container is created with runAsUser option by passing uid 0 to run as root priviledged user. Pod MUST be in Succeeded phase. This e2e can not be promoted to Conformance because a Conformant platform may not allow to run containers with 'uid 0' or running privileged operations. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support running as UID / GID. </ins> */ It("should run the container with uid 0 [LinuxOnly] [NodeConformance]", func() { createAndWaitUserPod(0)

Related discussion:
text: /kind cleanup /area conformance /area test /sig node /sig testing /sig architecture /assign /assign We have a number of tests that only have the tag that may make sense as tests, we should identify whether these tests cases meet (or could meet) the . We should open PR's to promote these if so. I would advise starting with the test/common cases
GitHub didn't allow me to assign the following users: mgdevstack, mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /kind cleanup /area conformance /area test /sig node /sig testing /sig architecture /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The tests in test/e2enode don't actually get run as part of Conformance as near as I can tell. If we want to run them as part of conformance, they need to be migrated into test/e2e/common. Some of the tests in e2enode may not be able to be ported over because they assume a level access we don't have in a conformance environment.
regarding this testcase: [sig-storage] HostPath should support r/w [NodeConformance]: It uses hostPath and privileged=true, to read/write from /tmp folder. Which would you suggest is the best orientation to overcome the privilege mode setting and allow its promotion?
/assign
Regarding , the suite runs the test only if the kubelet configuration was required to have the QOS (cgroups-per-qos) enabled. This configuration for the kubelet is selected at the time the cluster is set up. Looking for where this might be configured found: where is set to true. For other settings it is also configured to true. where is set to true. BUT also found where it is mentioned that the flag is no longer available. Questions: would it be ok to promote this test to be conformance, even it can be skipped based on configuration of the cluster? And not supported in the containerized kubelet?
I would consider cgroups to be an implementation detail that Conformance shouldn't be verifying
It uses hostPath and privileged=true, to read/write from /tmp folder.