Code change:
} /* <del> Release : v1.12 Testname: Security Context: readOnlyRootFilesystem=true. Description: when a container has configured readOnlyRootFilesystem to true, write operations are not allowed. This test is marked LinuxOnly since Windows does not support creating containers with read-only access. </del> <ins> Release : v1.15 Testname: Security Context, readOnlyRootFilesystem=true. Description: Container is configured to run with readOnlyRootFilesystem to true which will force containers to run with a read only root file system. Write operation MUST NOT be allowed and Pod MUST be in Failed state. At this moment we are not considering this test for Conformance due to use of SecurityContext. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support creating containers with read-only access. </ins> */ It("should run the container with readonly rootfs when readOnlyRootFilesystem=true [LinuxOnly] [NodeConformance]", func() { createAndWaitUserPod(true) }) /* <del> Release : v1.12 Testname: Security Context: readOnlyRootFilesystem=false. Description: when a container has configured readOnlyRootFilesystem to false, write operations are allowed. </del> <ins> Release : v1.15 Testname: Security Context, readOnlyRootFilesystem=false. Description: Container is configured to run with readOnlyRootFilesystem to false. Write operation MUST be allowed and Pod MUST be in Succeeded state. </ins> */ <del> It("should run the container with writable rootfs when readOnlyRootFilesystem=false [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should run the container with writable rootfs when readOnlyRootFilesystem=false [NodeConformance]", func() { </ins> createAndWaitUserPod(false) }) })

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.