kind, vgpu: Bump vgpu kind to k8s-1.25

[oshoval]

Since we don't use CPU manager on vgpu lane we can bump to k8s-1.25
and remove the cpu manager configuration due to
kubernetes-sigs/kind#2999 (affects k8s-1.24+ with cpu manager)

Rename vgpu lane to reflect the k8s version bump.

Kubevirtci Infra: kubevirt/project-infra#2653
Kubvirt infra: kubevirt/project-infra#2654

[kubevirt-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[oshoval]

/test check-up-kind-1.23-sriov

lets see it didn't affect sriov (since a common file was changed)

Note - didn't try to just bump to 1.25 and do config cpu manager, but without using it
which is basically an option, but it is more implicit, as it hides a broken feature.

[oshoval]

/test check-up-kind-1.23-sriov

[oshoval]

It breaks SRIOV tests that run on kubevirt
kubevirtci presubmit doesnt run them

[oshoval]

@vladikr @brianmcarey @dhiller @xpivarc
can you please take a look ?

this allows bumping vgpu lane to k8s-1.25
tested on kubevirt (both sriov and vgpu)
created infra PR as well

[kubevirt-bot]

@oshoval: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
check-up-kind-1.23-vgpu	9b14eed	link	false	/test check-up-kind-1.23-vgpu

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[oshoval]

https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirtci/979/check-up-kind-1.23-vgpu/1633477265524264960
fails because provider was renamed
tested under kubevirt with local hack
infra PR attached

[brianmcarey]

/lgtm

[xpivarc]

/lgtm
@dhiller Can I borrow your approve?

[ormergi]

Please note that the issues with kind 1.24+ could still occur w/o CPU manager see kubernetes-sigs/kind#2999 (comment).

On the the SRIOV take, it turned out to be flaky, tests were failing from time to time due to the missing permissions to /dev/null.
I suggest to run the GPU lanes with this PR changes on kubevirt/kubevirt few times (about 5) verifying that it's actually stable.

[oshoval]

Please note that the issues with kind 1.24+ could still occur w/o CPU manager see kubernetes-sigs/kind#2999 (comment).

Interesting

On the the SRIOV take, it can down to be flaky, tests were failing from time to time due to the missing permissions to /dev/null. I suggest to run the GPU lanes with this PR changes on kubevirt/kubevirt few times (about 5) verifying that it's actually stable.

I ran at least 4 times already and it was stable, I believe that as long as we don't touch the /dev/null we are fine
(which can be other bug of selinux imo, as we had on vm based providers).
In case we do see it after it is merged imo, we can simply move to k3d (assuming that it will work, as SR-IOV did).

Note that kind SR-IOV was not affected by this PR, kind SR-IOV still has cpu manager and k8s-1.23.

[dhiller]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhiller

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 [dhiller]

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

[oshoval]

Btw the lane of vpgu on kubevirtci is optional, this is why it was merged even that the old lane failed
(running it correctly passed)

Thanks