Repository navigation
docs(etcd): note that affinity is not applied to existing members - #3964
Merged
Merged
Conversation
scooby87
requested review from
IvanHunters,
Andrei Kvapil (kvaps),
Aleksei Sviridkin (lexfrei),
Timofei Larkin (lllamnyp) and
myasnikovdaniil
as code owners
August 26, 2026 11:25
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe Etcd affinity descriptions now state that the operator applies affinity when it creates or replaces member Pods. Running members are not rescheduled, so existing members adopt the rule only when replaced. ChangesEtcd affinity documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This documentation-only change clarifies when etcd affinity settings take effect without changing runtime behavior, so no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (4 skipped: 4 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
area/database
IvanHunters
approved these changes
Aug 26, 2026
IvanHunters
left a comment
IvanHunters
left a comment
Collaborator
There was a problem hiding this comment.
LGTM
Docs-only change: it appends one clarifying sentence to the affinity parameter description, warning that a newly-set affinity rule is not applied retroactively to already-running etcd members and only takes effect as each member is replaced.
Two things I checked before signing off:
- Sync across the generated artifacts. The same sentence lands identically in the source
@param(packages/extra/etcd/values.yaml:26), the renderedREADME.md:46,values.schema.json:70, and the cozyrdopenAPISchema(packages/system/etcd-rd/cozyrds/etcd.yaml). That is exactly whatmake generateemits from the source comment, so there is no doc drift. - Factual accuracy of the note. It holds by Kubernetes semantics on its own: the chart's affinity terms are all
...IgnoredDuringExecution(packages/extra/etcd/templates/etcd-cluster.yaml), so the scheduler never re-evaluates them for a running pod. Together with a quorum-aware operator that will not evict a healthy member just to satisfy affinity, the "takes effect only as each member is replaced, not retroactively" wording is correct and appropriately conservative.
No functional change and no test impact. Accurate, useful operational note.
scooby87
enabled auto-merge
August 26, 2026 14:41
The operator applies spec.affinity only when it creates or replaces a member Pod; it does not reschedule running members. Document that on the `affinity` value so operators do not expect the default (or a newly set rule) to redistribute already co-located members until each is replaced. Addresses the non-blocking review notes on #3962. Signed-off-by: Alexey Artamonov <[email protected]>
scooby87
force-pushed
the
docs/etcd-affinity-not-retroactive
branch
from
September 1, 2026 09:48
52466f4 to
6fdb5e0
Compare
Andrei Kvapil (kvaps)
pushed a commit
that referenced
this pull request
Sep 7, 2026
) ## What this PR does Documentation follow-up to #3962. Both reviewers (CodeRabbit and @androndo/@IvanHunters) noted that the new `affinity` value is not applied retroactively: the etcd-operator sets `spec.affinity` only when it creates or replaces a member Pod and never reschedules running members. On a cluster that already has co-located members (the exact failure #3962 targets) the default soft rule — or a newly set hard rule — takes effect only as each member is replaced. This adds that caveat to the `affinity` parameter documentation in `values.yaml` and regenerates `values.schema.json`, `README.md`, and the embedded `openAPISchema` in `etcd-rd`. No template or behaviour change; `make test` passes (20/20). The other inline note (the soft podAntiAffinity default overlaps the soft `topologySpreadConstraints`) was explicitly flagged as "fine to keep as-is", so no code change is made for it. > Note: this PR is stacked on `fix/etcd-soft-antiaffinity` (#3962) and will retarget to `main` once that merges. ### Screenshots n/a — no UI changes. ### Downstream repositories Doc-only change to an app chart (regenerated artifacts). No package added/renamed/removed, `kind`/`plural` unchanged, no installer values/assets/variants touched. No downstream follow-up required. - [x] No downstream repository is affected by this change ### Release note ```release-note NONE ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that etcd affinity rules apply when member Pods are created or replaced. * Noted that running members are not rescheduled retroactively; the rule takes effect as each member is replaced. * Updated the guidance consistently across configuration documentation and schema descriptions. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Documentation follow-up to #3962. Both reviewers (CodeRabbit and @androndo/IvanHunters) noted that the new
affinityvalue is not applied retroactively: the etcd-operator setsspec.affinityonly when it creates or replaces a member Pod and never reschedules running members. On a cluster that already has co-located members (the exact failure #3962 targets) the default soft rule — or a newly set hard rule — takes effect only as each member is replaced.This adds that caveat to the
affinityparameter documentation invalues.yamland regeneratesvalues.schema.json,README.md, and the embeddedopenAPISchemainetcd-rd. No template or behaviour change;make testpasses (20/20).The other inline note (the soft podAntiAffinity default overlaps the soft
topologySpreadConstraints) was explicitly flagged as "fine to keep as-is", so no code change is made for it.Screenshots
n/a — no UI changes.
Downstream repositories
Doc-only change to an app chart (regenerated artifacts). No package added/renamed/removed,
kind/pluralunchanged, no installer values/assets/variants touched. No downstream follow-up required.Release note
Summary by CodeRabbit