Adding FailingToStart Condition in cases of configuration errors.

[kannon92]

Enhancement Description

As per the discussion in kubernetes/kubernetes#113211 there is an interest in adding more information if a pod gets stuck due to a user configuaration error.

• One-line enhancement description (can be used as a release note): Add PodFailedToStart condition for configuration issues
• Kubernetes Enhancement Proposal: KEP-3815 : Add Condition for Pending Pods that are stuck due to configuration errors #3816
• Discussion Link: Enhancement: Marking a pending pod as failed after a certain timeout kubernetes#113211
• Primary contact (assignee): @kannon92
• Responsible SIGs: sig-node
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.28
  • Beta release target (x.y):
  • Stable release target (x.y):
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[kannon92]

/sig node
/wg batch

[alculquicondor]

nit: FailedToStart would be enough, as it's already a Pod Condition.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle stale

[alculquicondor]

/remove-lifecycle stale

[SergeyKanzhelev]

@kannon92 do you plan to work on this for 1.28 release?

[kannon92]

@kannon92 do you plan to work on this for 1.28 release?

To be honest I feel that as a new contributor this may have been too ambitious for me.

It seems like there are still many ways this KEP could go and I could use a bit of guidance here.

I found a few other KEPs I'm leading on sig-apps that may give me some good experience but not be as daunting..

I think this KEP is useful but it seems to me that there are still too many questions to target a 1.28 implementation. The code shouldn't be too difficult but I need some way to gather more requirements on different use cases.

Do you have any suggestions on how to proceed?

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle stale

[kannon92]

/close

I don't think I have any bandwidth on this for the future.

[k8s-ci-robot]

@kannon92: Closing this issue.

In response to this:

/close

I don't think I have any bandwidth on this for the future.

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.