template: specify priority class

[maiqueb]

What this PR does / why we need it:
This PR specifies the deployment's priority class, thus assuring the component is not preempted for other workloads with lesses priority.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Release note:

Specify the kubevirt-cluster-critical priorityClass for this deployment. It requires KubeVirt to be deployed.

[oshoval]

what happen if someone tries to deploy it without kubevirt ?
(and the PC doesnt exists)
well he cant anyhow because it listens to VM / VMI i guess so it is non issue

[maiqueb]

what happen if someone tries to deploy it without kubevirt ? (and the PC doesnt exists) well he cant anyhow because it listens to VM / VMI i guess so it is non issue

Yeah, that's kind of the point ... This is a project in the kubevirt org ...

I guess we should add to the docs a note indicating this must be used w/ kubevirt.

Let me check what happens though ...

[oshoval]

Please dont over invest on that, it also happens on KubeSecondaryDNS, and we concluded there it is fine
release note is more than enough imho

[oshoval]

/lgtm

[oshoval]

btw are you sure you want to use this pc ?
i remember that we used system-node-critical and system-node-critical built in pcs for sig network components.

We considered components that are mandatory for kubevirt to have higher prio than kubevirt,
if it was a DaemonSet it was highest prio pc, system-critical
if it was a Deployment that could be on any node, it was node-critical
Petr was in the loop, in case i am wrong

[maiqueb]

btw are you sure you want to use this pc ? i remember that we used system-node-critical and system-node-critical built in pcs for sig network components.

We considered components that are mandatory for kubevirt to have higher prio than kubevirt, if it was a DaemonSet it was highest prio pc, system-critical if it was a Deployment that could be on any node, it was node-critical Petr was in the loop, in case i am wrong

So you're suggesting we use system-node-critical instead ?

[oshoval]

yes please, wdyt?
if you want to make sure Petr is best with that

[phoracek]

For a deployment that other components relay on, use cluster critical. We don't have to be node critical - it is ok if the pod moves to a different node.

[phoracek]

@oshoval

We considered components that are mandatory for kubevirt to have higher prio than kubevirt, if it was a DaemonSet it was highest prio pc, system-critical if it was a Deployment that could be on any node, it was node-critical Petr was in the loop, in case i am wrong

I don't remember / understand this. Why would we set node critical for a deployment?

[oshoval]

I have a typo there / mix

I remember there are 2 classes, highest which is only for stuff that should be all on nodes
and one below that just need to be one stuff like Deployment that are allowed to switch but critical to have, such as KMP, as you said
forgot who is who

[maiqueb]

@oshoval please take another look

[oshoval]

/lgtm

as you said Petr
https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/

please rebase once #80

Thanks

[oshoval]

/lgtm

[maiqueb]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: maiqueb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [maiqueb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[oshoval]

Nit:
Release note: "It requires KubeVirt to be deployed." still true but not due to the PC / this PR
Thanks