Skip to content

Commit ee9bd26

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request kubernetes#9517 from omerap12/aep-doc
VPA: add lightweight AEP template for enhancement proposals
2 parents 249d8fe + 68a744e commit ee9bd26

2 files changed

Lines changed: 182 additions & 1 deletion

File tree

‎vertical-pod-autoscaler/enhancements/NNNN-aep-template/README.md‎

Lines changed: 181 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
<!--
2+
**Note:** When your AEP is complete, all of these comment blocks should be
3+
removed.
4+
5+
AEPs (Autoscaler Enhancement Proposals) are a lightweight version of Kubernetes
6+
KEPs, scoped to the Vertical Pod Autoscaler subproject. Use this template as
7+
the skeleton for new AEPs so reviewers see a consistent structure.
8+
9+
To get started:
10+
11+
- [ ] Open a tracking issue in kubernetes/autoscaler describing the problem.
12+
- [ ] Copy this directory to `NNNN-short-descriptive-title`, where `NNNN` is
13+
the issue number.
14+
- [ ] Fill in `Summary` and `Motivation` first — these are enough to start a
15+
design discussion.
16+
- [ ] Open a PR for the new AEP and iterate. Merging an AEP does not mean it
17+
is approved or complete; aim for tightly-scoped PRs per topic.
18+
- [ ] Fill in the remaining sections as the design firms up.
19+
20+
One AEP corresponds to one "feature" or "enhancement" for its whole lifecycle.
21+
If major changes emerge after implementation, edit the AEP rather than opening
22+
a new one.
23+
-->
24+
25+
# AEP-NNNN: Your short, descriptive title
26+
27+
<!--
28+
Keep the title short and descriptive. It is used in the TOC, commit messages,
29+
and PR titles.
30+
-->
31+
32+
<!-- toc -->
33+
- [Summary](#summary)
34+
- [Motivation](#motivation)
35+
- [Goals](#goals)
36+
- [Non-Goals](#non-goals)
37+
- [Proposal](#proposal)
38+
- [Design Details](#design-details)
39+
- [API Changes](#api-changes)
40+
- [Test Plan](#test-plan)
41+
- [Feature Enablement and Rollback](#feature-enablement-and-rollback)
42+
- [Graduation Criteria](#graduation-criteria)
43+
- [Version Skew](#version-skew)
44+
- [Kubernetes Version Compatibility](#kubernetes-version-compatibility)
45+
- [Implementation History](#implementation-history)
46+
- [Alternatives](#alternatives)
47+
<!-- /toc -->
48+
49+
## Summary
50+
51+
<!--
52+
A paragraph or two that captures what this AEP is about and why it matters.
53+
Write this section so that someone unfamiliar with the VPA internals can read
54+
it and understand the shape of the proposal.
55+
-->
56+
57+
## Motivation
58+
59+
<!--
60+
Explain why this change is worth doing. Link to issues, user reports, or
61+
previous discussions that show the problem is real. Reviewers will weigh the
62+
cost of the change against the motivation described here, so be concrete.
63+
-->
64+
65+
### Goals
66+
67+
<!--
68+
Bullet list of what this AEP is trying to achieve. Keep each goal testable —
69+
something a reviewer could point at later to decide whether the AEP succeeded.
70+
-->
71+
72+
### Non-Goals
73+
74+
<!--
75+
What is explicitly out of scope. Listing non-goals is often more valuable than
76+
listing goals — it keeps the discussion focused and prevents scope creep during
77+
review.
78+
-->
79+
80+
## Proposal
81+
82+
<!--
83+
Describe the proposed change at a high level. This is the "what", not the
84+
"how" — implementation details belong in Design Details below. A reviewer
85+
should be able to read this section and understand the user-visible behavior
86+
without reading any code.
87+
-->
88+
89+
## Design Details
90+
91+
<!--
92+
The "how". Include enough detail that a reader can evaluate whether the
93+
approach is sound. API types, flag names, component interactions, and any
94+
non-obvious behavior belong here. Code snippets and YAML examples are welcome
95+
when they clarify intent.
96+
-->
97+
98+
### API Changes
99+
100+
<!--
101+
If this AEP adds or modifies fields in the VPA API (`autoscaling.k8s.io/v1`),
102+
describe the new types, their validation rules, and default behavior. Include
103+
the Go struct definitions when possible. If there are no API changes, remove
104+
this subsection.
105+
-->
106+
107+
### Test Plan
108+
109+
<!--
110+
Describe how this change will be tested. At minimum, reviewers expect:
111+
- unit tests for new logic,
112+
- e2e tests for user-visible behavior (what scenarios will be covered?).
113+
Integration tests are not required for most AEPs, but mention them if they
114+
apply.
115+
-->
116+
117+
### Feature Enablement and Rollback
118+
119+
<!--
120+
Answer the following if this AEP is gated by a feature flag:
121+
122+
- Feature gate name:
123+
- Components depending on the feature gate (e.g. updater, admission-controller,
124+
recommender):
125+
- What happens when the gate is enabled?
126+
- What happens when the gate is disabled after being enabled? In particular,
127+
what happens to VPA objects already configured with the new field?
128+
129+
If the change is not gated (for example, a backward-compatible API extension
130+
with safe defaults), state that explicitly and explain why no gate is needed.
131+
-->
132+
133+
### Graduation Criteria
134+
135+
<!--
136+
A few bullets describing what needs to be true to move the feature from alpha
137+
to beta and from beta to GA. For most AEPs this is short — typical signals are
138+
"tests are stable for N releases", "no open bugs against the feature gate",
139+
and "positive user feedback". Remove this subsection if the change does not go
140+
through a graduation lifecycle (e.g. a pure bug fix).
141+
-->
142+
143+
### Version Skew
144+
145+
<!--
146+
The VPA ships multiple components (recommender, updater, admission-controller).
147+
Describe what happens when they are not all running the same version during a
148+
rollout — for example, a new recommender writing a field that an older updater
149+
does not understand. If the feature gate fully mitigates skew (the gate must
150+
be enabled on all components before the behavior takes effect), state that.
151+
Remove this subsection if only one component is affected.
152+
-->
153+
154+
### Kubernetes Version Compatibility
155+
156+
<!--
157+
Call out any minimum Kubernetes version this feature requires, and what the
158+
VPA does when running on an older version. Fill this in when the AEP depends
159+
on an upstream Kubernetes feature (e.g. KEP-1287 for in-place updates).
160+
Otherwise, remove this subsection.
161+
-->
162+
163+
## Implementation History
164+
165+
<!--
166+
Track major milestones using absolute dates (YYYY-MM-DD):
167+
- initial version
168+
- significant design changes
169+
- the first VPA release where the feature shipped
170+
- graduation to beta / GA
171+
-->
172+
173+
- YYYY-MM-DD: initial version
174+
175+
## Alternatives
176+
177+
<!--
178+
What other approaches were considered, and why were they rejected? Even a
179+
short note here helps future readers understand the design space and prevents
180+
the same alternatives from being re-proposed.
181+
-->

‎vertical-pod-autoscaler/enhancements/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
Lightweight enhancements proposals for Vertical Pod Autoscaler. Please use [KEP template](https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md) as guidance.
1+
Lightweight enhancements proposals (AEPs) for Vertical Pod Autoscaler. Please use the [AEP template](NNNN-aep-template/README.md) as the skeleton for new proposals.

0 commit comments

Comments
 (0)