Lower timeout seconds to 29

[kyranb]

Which component are you using?: The reccomender

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:

Digital Ocean is unable to auto upgrade the cluster because [Mutating webhook with a TimeoutSeconds value smaller than 1 second or greater than 29 seconds will block upgrades.](https://docs.digitalocean.com/products/kubernetes/resources/clusterlint-errors/#admission-controller-webhook-timeout)

Describe the solution you'd like.:

To change the default from 30 seconds to 29

To change the default from 30 seconds to 29

[jbartosik]

VPA admission controller already has a flag for this: --webhook-timeout-seconds.

Please reopen if this doesn't work for you. If you do reopen please explain why setting the flag won't work but changing default would (changing default will affect everyone so I'd rather not do it (and changing defaults to work well for everyone might be impossible)).

[kyranb]

Thanks, I appreciate you leaving the flag here for others to see. The reason that a change to the defaults would benefit everyone is that:

Admission control webhook timeouts can block upgrades, when the API call times out, due to an incorrectly configured TimeoutSeconds value. Since webhooks inherently add to API latency, we must stay within the recommended range in order for API requests to be successful. Specifically, this happens when an admission control webhook does not respond within 29 seconds.

This is taken from Clusterlint which Digital Ocean maintains as a set of best practises and is designed to work with all clusters, not just workloads running on Digital Ocean: https://docs.digitalocean.com/products/kubernetes/resources/clusterlint-errors/#admission-controller-webhook-timeout

[jbartosik]

I thought about this a bit more.

I think I might be ok with changing the default value of the flag after all. From what I saw VPA admission controller is taking much less time than 30s so it could be safe.

I still want to check:

• If VPA admission controller is also much faster than 30s in other places too,
• What value would make sense,
• Are others ok with the flag default value change / do we have any recommendations for doing that

[k8s-triage-robot]

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

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

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

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

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or 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 issues and 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 issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or 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: Closing this issue.

In response to this:

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

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

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or 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/test-infra repository.