/sig node

@ffromani Tagging you here since you reviewed the KEP. I believe this is the only code change required for this KEP for beta graduation. I'm thinking of adding more tests in this PR as well, if there is scope for more.

A bug related to the alpha code of this KEP was fixed in #129946, which has been backported to v1.32 also now.

UT may need an update. Others LGTM.

/hold

Sorry for the hold. I just wanted to confirm: is this PR running correctly and passing the e2e tests for this feature? I’ve made this kind of mistake before, and it seems like you might have run into the same issue as I did. Once you confirm that this PR passes the e2e tests for this feature, feel free to cancel the hold.

e2e tests seems to run properly when I run them locally with kubetest2. The error says timeout for scheduling pod. Trying rerunning the tests.

/retest

e2e tests seems to run properly when I run them locally with kubetest2. The error says timeout for scheduling pod. Trying rerunning the tests.

Are these test cases being triggered in the CI environment? Could you check this?

@HirazawaUi Thank you for pointing out the failures! The e2e tests have passed once I rerun them. It had failed because Pod scheduling had timed out earlier for some reason 🤔

/hold cancel

Are these test cases being triggered in the CI environment? Could you check this?

Ah sorry I didn't see your comment, looks like the test is being skipped. But I can also see that the tests for the parent KEP (PodLifecycleSleepAction, which is also in beta now) are also being skipped 🤔

Ah sorry I didn't see your comment, looks like the test is being skipped. But I can also see that the tests for the parent KEP (PodLifecycleSleepAction, which is also in beta now) are also being skipped 🤔

This is what I meant.

You need to submit a PR to https://github.com/kubernetes/test-infra to add a test job for PodLifecycleSleepActionAllowZero.

@pohly @kannon92 some feature gate owners might miss adding test jobs for their features in test-infra, unless the reviewer reminds them in the PR or the feature owner has already done some thorough exploration. I’ve seen a few cases like this, and I’ve made this mistake myself before. Are we lacking some documentation to guide people through this process?

/triage accepted

/lgtm

let's make it formal indeed

LGTM label has been added.

/lgtm

let's make it formal indeed

Please wait, the latest update missed some content and still needs modifications to pkg/features/kube_features.go.

/hold

Since this PR has already been approved, prevent accidental merging before submitting the fix. If you have already submitted the fix, feel free to remove the hold.

/lgtm
let's make it formal indeed

Please wait, the latest update missed some content and still needs modifications to pkg/features/kube_features.go.

/hold

Since this PR has already been approved, prevent accidental merging before submitting the fix. If you have already submitted the fix, feel free to remove the hold.

sorry, missed this update.

@sreeram-venkitesh the verify failure is around gates - it needs you to touch it to pass CI

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SergeyKanzhelev, sreeram-venkitesh, thockin

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

The pull request process is described here

Looking into the test failures..

Looking into the test failures..

The failure of the pull-kubernetes-unit job is unrelated to the changes in this PR. It seems that a previous change has made this job unstable. After the other jobs succeeded, we can retest it.

/test pull-kubernetes-unit

/lgtm
/hold cancel

LGTM label has been added.