Implement KEP-4420: Retry Generate Name#122887
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jpbetz The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Changelog suggestion -When the RetryGenerateName feature gate is enabled on the kube-apiserver,
- create requests using generateName are retried automatically by the apiserver when the generated name conflicts with an existing resource name, up to a max limit of 7 retries.
-This feature is in alpha.
+Added an alpha feature behind the `RetryGenerateName` feature gate. When the feature gate is enabled,
+and the API server is handling a **create** request that uses `.metadata.generateName`, then any
+name conflict between the generated name and an existing resource name triggers an automatic server-side
+retry with a different generated name (up to a maximum of 8 attempts). |
|
Once this new behavior is targeted at a release and merged / ready to merge, please document the feature gate. |
|
/assign @deads2k |
|
suggested doc updates seem fine. This fell out shockingly cleanly. Thinking through failure modes
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: b44c14f515077e2ee13c7f66777fd6f4f995664f |
|
/priority important-longterm |
|
/retest |
|
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
|
/retest |
|
/triage accepted |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Implements kubernetes/enhancements#4420
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/sig api-machinery