docs: add label and annotation propagation documentation#608
docs: add label and annotation propagation documentation#608khushiiagrawal wants to merge 2 commits intokserve:mainfrom
Conversation
Signed-off-by: khushiiagrawal <khushisaritaagrawal@gmail.com>
✅ Deploy Preview for elastic-nobel-0aef7a ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@sivanantha321 could you please take a look. thankyou. |
There was a problem hiding this comment.
Pull request overview
Adds documentation for LLMInferenceService label/annotation propagation and wires it into the docs navigation so users can discover and apply the feature across deployment modes (single-node, multi-node LWS, disaggregated prefill/decode, and scheduler/EPP).
Changes:
- Added a new doc page describing label/annotation propagation behavior, prefix allowlists, precedence, and examples.
- Included the new page in the Docusaurus sidebar under the LLMInferenceService section.
- Added cross-links to the new page from the LLMInferenceService Overview and Configuration Guide “Next steps”.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
sidebars.ts |
Registers the new label/annotation propagation doc in the LLMInferenceService sidebar section. |
docs/model-serving/generative-inference/llmisvc/llmisvc-overview.md |
Adds an “Advanced Topics” link pointing to the new propagation doc. |
docs/model-serving/generative-inference/llmisvc/llmisvc-label-propagation.md |
New documentation page describing propagation layers, allowlists, precedence, and examples. |
docs/model-serving/generative-inference/llmisvc/llmisvc-configuration.md |
Adds a “Next steps” link to the new propagation doc. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| | Field | Applies to | | ||
| |-------|------------| | ||
| | `spec.labels` / `spec.annotations` | Decode (main) workload pod templates. Also serves as the base for prefill pods when `spec.prefill` is set. | | ||
| | `spec.prefill.labels` / `spec.prefill.annotations` | Prefill workload pod templates (additive; overrides `spec.labels`/`spec.annotations` for the same key) | | ||
| | `spec.router.scheduler.labels` / `spec.router.scheduler.annotations` | Scheduler (EPP) pod template only | |
There was a problem hiding this comment.
The spec field paths referenced here (spec.labels/spec.annotations, spec.prefill.labels/spec.prefill.annotations, and spec.router.scheduler.labels/spec.router.scheduler.annotations) don’t appear in the generated CRD API reference for LLMInferenceServiceSpec / WorkloadSpec / SchedulerSpec in docs/reference/crd-api.mdx (those sections currently only list template/worker/prefill and router.scheduler.template). This mismatch can confuse readers and suggests either the doc is ahead of the published CRD schema or the field paths need to be adjusted to match the actual CRD. Please either (a) update/regenerate the CRD reference docs so these fields are discoverable, or (b) clarify the minimum KServe version and/or correct the field paths to what the CRD actually exposes (e.g., via template metadata fields if that’s the supported configuration surface).
…n in LLMInferenceService Signed-off-by: khushiiagrawal <khushisaritaagrawal@gmail.com>
|
@Jooho i have addressed the review, could you please take a look once, thanks! |
|
@khushiiagrawal Can you also update it under https://github.com/kserve/website/tree/main/versioned_docs/version-0.17. I think this is available in 0.17 release, right ? Also don't forget to update the sidebar for 0.17 https://github.com/kserve/website/blob/main/versioned_sidebars/version-0.17-sidebars.json. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| The top-level propagation flow (`.metadata.labels` / `.metadata.annotations` with allowlisted prefixes) is available in published CRD docs. | ||
|
|
||
| The spec-level propagation fields documented below (`spec.labels`, `spec.annotations`, `spec.prefill.labels`, `spec.prefill.annotations`, `spec.router.scheduler.labels`, and `spec.router.scheduler.annotations`) depend on the controller/CRD version installed in your cluster. If your generated API reference only shows `template`, `worker`, `prefill`, and `router.scheduler.template`, your cluster does not yet expose these fields. | ||
|
|
||
| To verify your installed schema, run `kubectl explain llminferenceservice.spec` and `kubectl explain llminferenceservice.spec.router.scheduler`. |
There was a problem hiding this comment.
The compatibility note says the “top-level propagation flow … is available in published CRD docs”, but the generated CRD API reference in this repo doesn’t document any propagation behavior—only standard .metadata fields. Consider rephrasing to avoid implying the behavior is defined/guaranteed by the CRD schema (e.g., state it’s controller behavior and point readers to the API reference for schema validation).
| The top-level propagation flow (`.metadata.labels` / `.metadata.annotations` with allowlisted prefixes) is available in published CRD docs. | |
| The spec-level propagation fields documented below (`spec.labels`, `spec.annotations`, `spec.prefill.labels`, `spec.prefill.annotations`, `spec.router.scheduler.labels`, and `spec.router.scheduler.annotations`) depend on the controller/CRD version installed in your cluster. If your generated API reference only shows `template`, `worker`, `prefill`, and `router.scheduler.template`, your cluster does not yet expose these fields. | |
| To verify your installed schema, run `kubectl explain llminferenceservice.spec` and `kubectl explain llminferenceservice.spec.router.scheduler`. | |
| The top-level propagation flow (`.metadata.labels` / `.metadata.annotations` with allowlisted prefixes) is implemented by the controller. The published CRD/API reference documents the `.metadata` schema but does not itself define or guarantee propagation behavior. | |
| The spec-level propagation fields documented below (`spec.labels`, `spec.annotations`, `spec.prefill.labels`, `spec.prefill.annotations`, `spec.router.scheduler.labels`, and `spec.router.scheduler.annotations`) depend on the controller/CRD version installed in your cluster. If your generated API reference only shows `template`, `worker`, `prefill`, and `router.scheduler.template`, your cluster does not yet expose these fields in its schema. | |
| To verify which fields your installed CRD schema provides, run `kubectl explain llminferenceservice.spec` and `kubectl explain llminferenceservice.spec.router.scheduler`. Propagation behavior for any of these fields is handled by the controller. |
Fixes #607
Proposed Changes
docs/model-serving/generative-inference/llmisvc/llmisvc-label-propagation.md) covering the label and annotation propagation feature for LLMInferenceService, merged in feat(llmisvc): enable label/annotation propagation kserve#5009 as requested by @sivanantha321.sidebars.ts.The documentation covers:
k8s.v1.cni.cncf.io,kueue.x-k8s.io,prometheus.io) and labels (kueue.x-k8s.io)spec.labels/spec.annotations,spec.prefill.labels/spec.prefill.annotations,spec.router.scheduler.labels/spec.router.scheduler.annotations