feat: add podLabels to pod template#435
Conversation
Adds an optional podLabels value merged into the pod template labels only
(the immutable selector is untouched). Enables scheduling controls that key
off pod labels, e.g. opting a workload into an EKS Fargate profile via
{ parcellab.dev/compute: fargate }.
common 1.3.9 -> 1.3.10, microservice 0.5.8 -> 0.5.9.
There was a problem hiding this comment.
Pull request overview
This PR extends the shared common pod template used by the charts (microservice/cronjob/job/deployment/rollout) to support optional user-defined pod-template labels via a new podLabels value, primarily to enable scheduling/routing behaviors (e.g., EKS Fargate profiles) without modifying per-app templates.
Changes:
- Add support for
.Values.podLabelsincommonpod templatemetadata.labels(pod template only). - Document
podLabels: {}inmicroservice/values.yaml. - Bump chart versions for
commonandmicroservice.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| parcellab/common/templates/_pod.tpl | Adds rendering of user-provided podLabels into pod template labels. |
| parcellab/microservice/values.yaml | Documents the new podLabels value for microservice consumers. |
| parcellab/common/Chart.yaml | Bumps common chart version to 1.3.10. |
| parcellab/microservice/Chart.yaml | Bumps microservice chart version to 0.5.9. |
Render pod labels via a single dict merge with managed (selector) labels taking precedence, preventing user podLabels from duplicating keys or overriding selector labels (which would break the Deployment/Rollout selector). Also declare podLabels in common/values.yaml. Addresses review feedback on #435.
The podLabels feature lives in the shared common library, so it already applies to every chart. Bump these consumers (which bundle common via file://) so chart-releaser republishes them carrying common 1.3.10 — making podLabels available across all chart types, not just microservice.
|
Inconsistent
In Helm, a library chart's Suggest adding |
Library defaults aren't inherited by consumer charts, so declare podLabels: {}
in each so it's discoverable for all chart types, not just microservice.
Adds an optional
podLabelsvalue to the sharedcommonpod template, merged into the pod template labels only — the (immutable) Deployment/Rollout selector is untouched, and managed/selector labels always win on collision (user labels can only add new keys).Enables scheduling controls that key off pod labels without per-app template hacks. First consumer: opting a workload into the EKS Fargate isolated tier (per-pod Firecracker microVMs) via
podLabels: { parcellab.dev/compute: fargate }, which an EKS Fargate profile selects.Changes
common/_pod.tpl: merge.Values.podLabelsinto pod templatemetadata.labelsvia a single dict merge (managed labels take precedence — no duplicate keys, selector can't be broken)common/values.yaml+microservice/values.yaml: documentpodLabels: {}common(the feature lives incommon, so it applies to all chart types — not just microservice):common1.3.9 → 1.3.10microservice0.5.8 → 0.5.9cronjob0.5.1 → 0.5.2monolith0.5.9 → 0.5.10worker-group0.3.4 → 0.3.5