Possible conflicts between lifecycle-cpu-isolation and lifecycle-pod-scheduling conditions to pass

[ramperher]

While testing the new test called lifecycle-cpu-isolation, included in https://github.com/test-network-function/cnf-certification-test/pull/434, I've found some incompatibilities between this test suite and lifecycle-pod-scheduling one.

I've been testing lifecycle-cpu-isolation with DCI, thanks to this change. I managed to fulfill the conditions needed to pass the test, as you can see in this DCI job. However, as a consequence of these modifications in the pods under test, lifecycle-pod-scheduling is now failing.

I think the problem is the following:

• In order to pass lifecycle-cpu-isolation test, the pods under test need to include a runtimeClassName, among other requirements.
• In our OCP clusters, we already define a default RuntimeClass like this, which is created as a consequence of a PerformanceProfile definition:

$ oc get runtimeclass -o json
{
    "apiVersion": "v1",
    "items": [
        {
            "apiVersion": "node.k8s.io/v1",
            "handler": "high-performance",
            "kind": "RuntimeClass",
            "metadata": {
                "creationTimestamp": "2022-09-04T06:35:43Z",
                "name": "performance-cnf-basic-profile",
                "ownerReferences": [
                    {
                        "apiVersion": "performance.openshift.io/v2",
                        "blockOwnerDeletion": true,
                        "controller": true,
                        "kind": "PerformanceProfile",
                        "name": "cnf-basic-profile",
                        "uid": "6015b5e4-3f2e-4355-b8f7-7ed1b2129f09"
                    }
                ],
                "resourceVersion": "39865",
                "uid": "3cf9e8b8-7d10-4284-8c4a-95bd5615a914"
            },
            "scheduling": {
                "nodeSelector": {
                    "node-role.kubernetes.io/worker": ""
                }
            }
        }
    ],
    "kind": "List",
    "metadata": {
        "resourceVersion": ""
    }
}

• The problem is that the RuntimeClass usually defines a nodeSelector for scheduling the pods, like the example above, and it's exactly the cause of failure in lifecycle-pod-scheduling test.

So, my question is, how can we deal with this kind of issue?

[ramperher]

CC @sebrandon1, maybe you are interested in checking this, as you included the CPU isolation test.

[sebrandon1]

Thanks for the report! I'll take a look.

[sebrandon1]

Fixed in #498