doc: add the label override doc#71
Conversation
Signed-off-by: Ryan Zhang <yangzhangrice@hotmail.com>
There was a problem hiding this comment.
Pull request overview
Adds documentation for using member-cluster label values as templated variables in override JSON patches, expanding the reserved variable list and providing new examples across the how-to and concepts docs.
Changes:
- Document new reserved variable
${MEMBER-CLUSTER-LABEL-KEY-<label-key>}alongside${MEMBER-CLUSTER-NAME}. - Add examples demonstrating label-driven overrides for both
ResourceOverrideandClusterResourceOverride. - Update the concepts doc to explicitly note variable support and include additional end-to-end examples.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| content/en/docs/how-tos/resource-override.md | Documents the new label-key variable and adds a ResourceOverride example using cluster label variables. |
| content/en/docs/how-tos/cluster-resource-override.md | Documents the new label-key variable and adds a ClusterResourceOverride example using cluster label variables. |
| content/en/docs/concepts/override.md | Extends the reserved-variable section and adds concept-level examples for both override types. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| placement: | ||
| name: crp-example | ||
| resourceSelectors: | ||
| - group: apps |
There was a problem hiding this comment.
In this YAML example, the list item under resourceSelectors uses - group: apps with an extra space after -, which also misaligns the following keys (kind, version, name) and can make the snippet invalid YAML in some parsers. Use consistent indentation (e.g., - group: apps) so all keys in the mapping align.
| - group: apps | |
| - group: apps |
| path: /metadata/annotations | ||
| value: | ||
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} |
There was a problem hiding this comment.
This JSONPatch uses op: add at path /metadata/annotations with an object value, which will set/replace the entire annotations map and may unintentionally drop any existing annotations on the resource. If the intent is to add these keys non-destructively, patch individual keys (e.g., /metadata/annotations/target-region and /metadata/annotations/target-env) or explicitly call out in the text that existing annotations will be overwritten.
| path: /metadata/annotations | |
| value: | |
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} | |
| path: /metadata/annotations/target-region | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-region}" | |
| - op: add | |
| path: /metadata/annotations/target-env | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-env}" |
| path: /metadata/annotations | ||
| value: | ||
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} |
There was a problem hiding this comment.
This example adds annotations by patching /metadata/annotations with an object value. That operation sets/replaces the whole annotations map and can remove any existing annotations on the ClusterRole. If you mean to append keys, patch /metadata/annotations/target-region and /metadata/annotations/target-env (or clarify that this overwrites existing annotations).
| path: /metadata/annotations | |
| value: | |
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} | |
| path: /metadata/annotations/target-region | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-region}" | |
| - op: add | |
| path: /metadata/annotations/target-env | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-env}" |
| - `${MEMBER-CLUSTER-NAME}`: this will be replaced by the name of the `memberCluster` that represents this cluster. | ||
| - `${MEMBER-CLUSTER-LABEL-KEY-<label-key>}`: this will be replaced by the value of the label with the key `<label-key>` on the `memberCluster`. For example, `${MEMBER-CLUSTER-LABEL-KEY-region}` will be replaced by the value of the `region` label on the target member cluster. If the label does not exist on the cluster, the override will fail with an error. | ||
|
|
||
| For example, to add a label to the `ClusterRole` named `secret-reader` on clusters with the label `env: prod`, | ||
| These variables are supported in both `ClusterResourceOverride` and `ResourceOverride`. | ||
|
|
There was a problem hiding this comment.
These docs introduce ${MEMBER-CLUSTER-LABEL-KEY-<label-key>}, but the generated API reference pages still list only ${MEMBER-CLUSTER-NAME} as a supported reserved variable (e.g., content/en/docs/api-reference/placement.kubernetes-fleet.io/v1.md and v1beta1.md). Please update/regenerate the API reference so it matches the documented behavior and users can discover the new variable from the type docs.
| path: /metadata/annotations | ||
| value: | ||
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} |
There was a problem hiding this comment.
This ResourceOverride example uses op: add at /metadata/annotations with an object value, which replaces the entire annotations map and can delete existing annotations. If the intent is to add these annotations while preserving existing ones, patch the individual keys under /metadata/annotations/... or clarify that this overwrites all annotations.
| path: /metadata/annotations | |
| value: | |
| {"target-region":"${MEMBER-CLUSTER-LABEL-KEY-region}", "target-env":"${MEMBER-CLUSTER-LABEL-KEY-env}"} | |
| path: /metadata/annotations/target-region | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-region}" | |
| - op: add | |
| path: /metadata/annotations/target-env | |
| value: "${MEMBER-CLUSTER-LABEL-KEY-env}" |
There was a problem hiding this comment.
where did you get this? This is actually wrong
add the label override doc to show examples how to use lable key on member cluster as a templating mechanism.