[DO NOT REVIEW] [TEST] Remove NoSchedule taints for control-planes as well as masters

[iholder101]

What this PR does

Before this PR:

After this PR:

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

The following alternatives were considered:

Links to places where the discussion took place:

Special notes for your reviewer

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note

[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

[kubevirt-bot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

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.

[iholder101]

/test all

[iholder101]

/approve
/lgtm
/hold

I'm doing this solely for running the whole test suite. This PR is NOT intended to merge.

[kubevirt-bot]

@iholder101: you cannot LGTM your own PR.

In response to this:

/approve
/lgtm
/hold

I'm doing this solely for running the whole test suite. This PR is NOT intended to merge.

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.

[brianmcarey]

/test pull-kubevirt-e2e-kind-sriov

[iholder101]

@brianmcarey @oshoval can you please LGTM in order to run the whole test suite?
This PR will not get in by any means.

[oshoval]

you dont need to lgtm,
just run please /test the vgpu and sriov ones

[iholder101]

you dont need to lgtm, just run please /test the vgpu and sriov ones

Don't you want to run the other lanes as well to be on the safe side?

[oshoval]

/test pull-kubevirt-e2e-kind-1.27-vgpu

[oshoval]

dont you need it in combination of #11659 ?

[iholder101]

dont you need it in combination of #11659 ?

I can cherry pick the commits to here if you want to. But then we'd be testing two things at ones. Your call.

[oshoval]

dont you need it in combination of #11659 ?

I can cherry pick the commits to here if you want to. But then we'd be testing two things at ones. Your call.

well they are connected anyhow, sgtm to test together

[oshoval]

you dont need to lgtm, just run please /test the vgpu and sriov ones

Don't you want to run the other lanes as well to be on the safe side?

kind doesnt affect them, no need
i dont know but what your other PR does, your call

[iholder101]

/test pull-kubevirt-e2e-kind-sriov
/test pull-kubevirt-e2e-kind-1.27-vgpu
/test all

[iholder101]

/approve cancel

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from iholder101. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[dhiller]

@iholder101 KubeVirtCI kind providers are completely independent from the "normal" KubeVirtCI k8s providers. IMHO it is enough to only run the kind lanes for the changed kind providers.

[dhiller]

And wrt to triggering the test lanes: an lgtm is not required, you can trigger any test lane manually at any time. As you saw test all triggered all of them.

[dhiller]

The above holds true for any KubeVirt org member btw.

[iholder101]

And wrt to triggering the test lanes: an lgtm is not required, you can trigger any test lane manually at any time. As you saw test all triggered all of them.

Are you sure?
I see that some of the lanes are "Pending" and some are "Expected". IIUC one means "still running" and one means "haven't start running yet". Am I completely off?

[dhiller]

The 1.28 and 1.27 are not triggered automatically any more, however manually triggering any lane should still be possible. I'm going to check whether prow jobs have been created. (Note that if no link is visible this might just mean that the test pod has not been created)

[dhiller]

(am shortly off for now, will check later)

[oshoval]

The 1.28 and 1.27 are not triggered automatically any more, however manually triggering any lane should still be possible. I'm going to check whether prow jobs have been created. (Note that if no link is visible this might just mean that the test pod has not been created)

those are phase 2 indeed, just forget them, it is enough to test the latest (1.29) in this PR (only because there are additional changes beside kind)

[dhiller]

/test pull-kubevirt-e2e-kind-sriov /test pull-kubevirt-e2e-kind-1.27-vgpu /test all

What I think has happened here is that the issuing of test all additionally to the test whatever has not come through to the trigger plugin, I guess because it didn't stand alone but additionally to the other test triggers (who had been superfluous anyway when using test all).

[oshoval]

/test pull-kubevirt-e2e-kind-sriov /test pull-kubevirt-e2e-kind-1.27-vgpu /test all

What I think has happened here is that the issuing of test all additionally to the test whatever has not come through to the trigger plugin, I guess because it didn't stand alone but additionally to the other test triggers (who had been superfluous anyway when using test all).

if you mean why the phase 2 didnt run, it is because they are "always_run: false"
"test all" won't trigger them,
unless you meant that also the phase 1 didn't run due to this command stacking

[oshoval]

sriov and vgpu passed, i think you can close the PR, thanks
(also all other phase 1 lanes passed, generate is expected to fail)
windows is not tested but will be tested as part of the kubevirt PR anyhow

[dhiller]

if you mean why the phase 2 didnt run, it is because they are "always_run: false" "test all" won't trigger them, unless you meant that also the phase 1 didn't run due to this command stacking

I think that is not true. always_run: false means that the lanes are not triggered automatically, where triggering with test all should still work. If that wasn't true, the phrase test all would be very misleading, as it didn't mean all but only some, right?

@oshoval do you have evidence or code pointers that it should behave as you said?

[iholder101]

sriov and vgpu passed, i think you can close the PR, thanks (also all other phase 1 lanes passed, generate is expected to fail) windows is not tested but will be tested as part of the kubevirt PR anyhow

Great!
So can you please approve the other PR? Or is there anything missing?

[oshoval]

if you mean why the phase 2 didnt run, it is because they are "always_run: false" "test all" won't trigger them, unless you meant that also the phase 1 didn't run due to this command stacking

I think that is not true. always_run: false means that the lanes are not triggered automatically, where triggering with test all should still work. If that wasn't true, the phrase test all would be very misleading, as it didn't mean all but only some, right?

@oshoval do you have evidence or code pointers that it should behave as you said?

it always was like that, always_run = false never run with test all, not related even the phased plugin
for example we had the bump_kubevirt_kuebvirtci manual lane (which was removed)
it never ran with "test all"

Tide filters according ps.ShouldRun, if you think code evidence is required (imho it doesn't)
than i would bet the trigger plugin have same logic to find out what should run

one can also add a new dummy presubmit which is always_run false and see what happens
it doesn't make sense to run with /test all the non always_run, but just the presubmits that are anyhow always_run
this concept is all over tide and prow as far as i saw

[oshoval]

sriov and vgpu passed, i think you can close the PR, thanks (also all other phase 1 lanes passed, generate is expected to fail) windows is not tested but will be tested as part of the kubevirt PR anyhow

Great! So can you please approve the other PR? Or is there anything missing?

it is already lgtmed

[oshoval]

@dhiller
https://github.com/kubernetes-sigs/prow/blob/db89760fea406dd2813e331c3d52b53b5bcbd140/pkg/plugins/trigger/pull-request.go#L356
for example, not sure if "/test all" reach exactly here, but educated guess it uses FilterPresubmits

		shouldRun, err := presubmit.ShouldRun(branch, changes, forced, defaults)
		if err != nil {
			return nil, fmt.Errorf("%s: should run: %w", presubmit.Name, err)
		}

More precise it reach handleGenericComment and then FilterPresubmits

[dhiller]

/test all

[dhiller]

Hm, interesting. Thanks for educating me @oshoval! I still believe that then the wording of test all is very misleading. And I also believe that the behaviour has changed at some point.

[kubevirt-bot]

@iholder101: 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
pull-kubevirt-generate	23eddb9	link	true	/test pull-kubevirt-generate

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.

[iholder101]

Thanks everyone!
/close

[kubevirt-bot]

@iholder101: Closed this PR.

In response to this:

Thanks everyone!
/close

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.