move stable node feature specific jobs to release-blocking

[AnishShah]

After delaking eviction tests in kubernetes/kubernetes#127874 and kubernetes/kubernetes#126927, we have almost 2 weeks of green runs for eviction tests - https://testgrid.k8s.io/sig-node-containerd#node-kubelet-containerd-eviction.

We should make these jobs release-blocking since Eviction is a stable feature.

/sig node
/assign @SergeyKanzhelev

[AnishShah]

/assign @yujuhong

[kannon92]

These tests have been flaky for a long time. Even though they are green, why choose this over other green tests? I’d also like to see why the crio eviction jobs are still flaky. Containerd seems fine but crio still flakes on pid eviction.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• config/jobs/kubernetes/sig-node/OWNERS

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

[AnishShah]

Even though they are green, why choose this over other green tests?

I intend to make the CPU, memory, and topology manager tests release-blocking again. These tests have been stable recently, so I believe it's appropriate to reinstate their blocking status. I'm not entirely sure why they were initially made non-blocking, but I suspect it was due to flakiness in the past.

[kannon92]

So SIG-Node-Release-Blocking is a bit of a misnomer. Release does not look at that board to determine if there is a problem for the release. They would look at their sig-release board and we have a different process to include that to consider them "release blocking". Serial tests are mostly used by us to determine issues.

I'm happy to move these tests to release blocking but I wanted to clarify this.

[AnishShah]

They would look at their sig-release board and we have a different process to include that to consider them "release blocking"

Sounds good. I was aware of this. What's the process to include these tests in sig-release dashboard? I can follow-up on this too

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[yujuhong]

So SIG-Node-Release-Blocking is a bit of a misnomer.

Maybe we can rename that to avoid further confusion? Say, "SIG-Node-Release-Informing"?

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

Details

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/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-sigs/prow repository.

[yujuhong]

@AnishShah do you still plan to work on this?