fix: Device Plugin daemonset keep restarting

[armandpicard]

Define an ordering of the NodeSelectorRequirement in the daemonset to avoid the daemonset to be unstable when policies come in different order.

Fixes #804

[github-actions]

Thanks for your PR,
To run vendors CIs, Maintainers can use one of:

• /test-all: To run all tests for all vendors.
• /test-e2e-all: To run all E2E tests for all vendors.
• /test-e2e-nvidia-all: To run all E2E tests for NVIDIA vendor.

To skip the vendors CIs, Maintainers can use one of:

• /skip-all: To skip all tests for all vendors.
• /skip-e2e-all: To skip all E2E tests for all vendors.
• /skip-e2e-nvidia-all: To skip all E2E tests for NVIDIA vendor.
  Best regards.

[coveralls]

Pull Request Test Coverage Report for Build 11767732959

Details

• 15 of 16 (93.75%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.09%) to 45.543%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
controllers/helper.go	15	16	93.75%

Totals
Change from base Build 11613650922:	0.09%
Covered Lines:	6811
Relevant Lines:	14955

---

💛 - Coveralls

[ykulazhenkov]

Hi, @armandpicard. Thanks for the PR.

I think these sorting [1,2] in the controllers code should keep the order stable without the changes from this PR.
[1] https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/master/controllers/sriovoperatorconfig_controller.go#L131

[2] https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/master/controllers/sriovnetworknodepolicy_controller.go#L127

Note: ByPriority uses Priority + Name of the CR

sriov-network-operator/api/v1/helper.go

Line 347 in 92fee7b

func (a ByPriority) Less(i, j int) bool {

The 91cf86c (the one that introduced [1]) was added pretty recently.

I think the issue with the unstable order of the selectors should not exist in the master branch.
Which version of the operator are you using?

[armandpicard]

Hi @ykulazhenkov.
I'm not 100% sure of the exact version we use as in our case srio-network-operator is deployed by mellanox network-operator(24.7.0). By the look of the bindata in the container it is at least 8 mouth old so it doesn't have the fix.
I'll close the MR and the Issue as sriov-network-operator from master was able to get the daemonset stable with our SrioNetworkNodePolicy's