Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/lifecycle frozen
/remove-lifecycle stale
/remove-lifecycle rotten

@thockin is it still something that requires a fix in the current API?
/assign

@thockin can you please elaborate?
/triage needs-information

sig-node triage meeting:

@thockin is suggesting startupProbes to have success threshold as 2

/triage accepted
/priority backlog

The issue I meant is that the API has a field which CAN be changed, but MUST NOT be changed in some contexts. A field which "must be 1" should not exist.

/remove-triage needs-information

Actually I don't see why it should not be changed to something bigger than 1... what could go wrong?
Here is the code.

Maybe we just have to edit the comment and label this issue as a documentation one.

#106025

The prooblem is it implies an in-between state that is neither "fully alive" nor "dead enough to restart", which has no bounds on time and unclear semantics.

Specifically, the discussion from #106025 (comment) and down. I could be OK with it, if we define the semantics, but it's not as simple as I originally thought when I opened that PR (shocking, I know).

I see, and what if we simply ignore the value and default to 1 with liveness and startup, updating the comments to have proper documentation?

As a general rule, we don't want to change any input a user specifically provided. If they say nothing, we can default it. If they say 42, we cannot unilaterally change it to 1 (or risk incurring an apply loop, where the client says "I wanted 42", they update to 42, we blast it back to 1, repeat. Better to fail.

startupProbe seems logical, but livenessProbe needs more semantic definition.