This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/assign @AxeZhan

Should we just revert the entire PR?

Ideally it would be better to revert the entire test including its movement to node conformance.

Ideally it would be better to revert the entire test including its movement to node conformance.

I remember looking at test history when reviewed the PR and it was stable green. This shows it was reasonably stable for a long time: https://storage.googleapis.com/k8s-triage/index.html?date=2024-11-06&pr=1&text=unexpected%20delay%20duration%20before%20killing%20the%20pod I don't remember seeing these 3 flakes it shows currently from before the promotion to conformance. Need to look deeper into those

Looking at that I don't know if we had this test running as a periodic..

/lgtm
/approve

LGTM label has been added.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, SergeyKanzhelev

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

The pull request process is described here

E2eNode Suite: [It] [sig-storage] HostPath should support r/w [NodeConformance] expand_more

/test pull-kubernetes-node-e2e-containerd

/retest

Seems the be unrelated issue

#128619 (comment)

I don't see any periodics that are actually running this test before the merge of the PR.

Looking at what you linked @SergeyKanzhelev I don't think this test was ever running as a periodic. There was one PR that it ran on a few weeks ago but I don't see actual test runs for this feature.

It looks like when we promoted this test to node conformance we started running it and it shows flakes. I worry that we will still have these flakes even if we lower the sleep value.

should we revert the promotion to NodeConformance entirely then if we can't find anywhere it was running flake-free, rather than try to deflake in master?

Isn't this making the timing tighter? Maybe I misunderstood the flake?

/hold

I didn't review the PR closely, I just assumed it was reverting to a more stable version of the test

#128619 (comment) indicates maybe there never was a stable version of the test

Would be good to figure out what we're doing in a single rollback or edit asap

Would be good to figure out what we're doing in a single rollback or edit asap

I don't feel comfortable promoting the feature to GA in a pod lifecycle if we are not able to say if is being tested
My suggestion

1. rollback the entire PR with the feature promotion Graduate PodLifecycleSleepAction to GA #128046 (postpone it for 1.33)
2. figure out if the test are running or not and provide proof of stability
3. promote to GA in 1.33 with guarantees

https://github.com/kubernetes/kubernetes/pull/128046/files#r1831730521

The only job that runs this test is pull-kubernetes-e2e-gce-cos-alpha-features.

I agree with @aojea. I will put up a revert and we will require a periodic so we can monitor stability of this test before promoting to GA.

#128627 is up.

/close

@SergeyKanzhelev: Closed this PR.