docs(contributor): document exposing scheduling knobs without new flags#1379
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA new section, "Exposing Scheduling Knobs Without New Flags," is added to Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/contributor/component.md`:
- Around line 193-221: The section conflates path routing with value precedence
by including nodeScheduling paths as the first item in a "three layers"
precedence list. Restructure the documentation to separate these concerns:
first, explain nodeScheduling paths as a routing mechanism that maps chart value
paths to node classes (system/accelerated), making clear it is metadata for path
selection, not a value layer. Then, separately present the actual three layers
of value precedence: component value defaults (in values.yaml/overlays),
deploy-time overrides (--set/--dynamic), and describe how merge order works
across these layers. This clarifies that nodeScheduling operates orthogonally to
the merge precedence, routing which values get applied rather than participating
in the precedence ordering itself.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: f9d9e4cd-c00d-4668-923c-1fb1bf070a7b
📒 Files selected for processing (1)
docs/contributor/component.md
Generalize node-placement guidance for recipe/component authors: model placement as value paths across registry nodeScheduling, component value defaults, and deploy-time --set/--dynamic overrides rather than adding a new CLI flag per knob. Separates path routing (nodeScheduling) from value precedence, includes a decision table and the chart-must-render caveat (slinky-slurm-operator as worked example).
4333df8 to
f8e7255
Compare
Coverage Report ✅
Coverage BadgeNo Go source files changed in this PR. |
Summary
Adds a contributor-docs section explaining how to expose node-placement (and other chart) knobs through existing value-path primitives instead of adding a new CLI flag per knob.
Motivation / Context
A contributor writing a new recipe asked whether to add per-role node-selector/toleration flags (e.g.
slurm-controlplane-node-selector,slurm-gpu-worker-node-selector). AICR already covers this via thesystem/acceleratednode classes plus--set/--dynamic, so the answer is "no new flags" — but that pattern was not written down. This generalizes the guidance for any component author.Fixes: N/A
Related: N/A
Type of Change
Component(s) Affected
docs/,examples/)Implementation Notes
Extends
docs/contributor/component.md, right aftervalueOverrideKeys, since the pattern builds on both thenodeSchedulingnode-class paths and--setrouting. Covers the three override layers (registry paths → component value defaults → deploy-time--set/--dynamic), a decision table for where a knob belongs, and the "chart must actually render the path" caveat (withslinky-slurm-operatoras the worked example already in the registry).Testing
./tools/check-docs-mdx docs/contributor/component.md # OK: all doc files are MDX-safeDoc-only change; no Go sources touched.
Risk Assessment
Rollout notes: N/A
Checklist
make testwith-race)make lint)git commit -S)