kubevirt-bot
commented
3 years ago Hi @oshoval. Thanks for your PR.
I'm waiting for a k8snetworkplumbingwg member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
oshoval
EdDev
AlonaKaplan
RamLavi
phoracek
Manual cherry-pick of https://github.com/k8snetworkplumbingwg/ovs-cni/pull/164
As part of https://bugzilla.redhat.com/show_bug.cgi?id=1953482 We are adding Priority Class [1] to each network component.
The motivation is to make the control plane pods less sensitive to preemption than user workloads.
Pods that are node specific will have the higher build-in priority, since preempting them from a specific node, makes them unavailable until they are rescheduled on that specific node. Pods that are network control plane, but are not node specific will have system-cluster-critical, which would still make them more important than user and custom workloads, but less than system-node-critical.
Since ovs-cni pod should run on each node, assign system-node-critical pc to it.
[1] https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
Signed-off-by: Or Shoval oshoval@redhat.com