Skip to content

feat(chart): podLabels on the chart's pods - #55

Draft
QuentinBisson wants to merge 2 commits into
giantswarmfrom
carry/pod-labels
Draft

QuentinBisson wants to merge 2 commits into
giantswarmfrom
carry/pod-labels

Conversation

@QuentinBisson

Copy link
Copy Markdown

Problem

Substrate's OTLP export reaches no tenant (giantswarm/giantswarm#36711). The OTLP gateway takes the tenant from the pod label observability.giantswarm.io/tenant when an export carries no header. The chart has no pod-label key and no OTLP headers key, so every Substrate span, metric and log is dropped as tenant-less.

Change

Cherry-pick of kagent-dev#48, plus its FORK.md row. podLabels goes on every long-running pod next to app, which it cannot replace. The rustfs-bucket-init Job does not get it, because its pod template is immutable. The default render is unchanged (make verify-helm-template, helm unittest 43/43). Rebase-merge: the ledger row names the pre-merge SHA b05a7fbc, so the next ledger update corrects it. This ships in 1.1.0 with the re-pin; the agent-platform side is a separate PR.

A multi-tenant telemetry collector commonly takes a pod's tenant from a
pod label, the one signal a headerless OTLP export carries. The chart
sets only its own `app` label on every pod and offers no way to add one.

`podLabels` is added to every long-running pod template, next to `app`,
which it cannot replace: `app` is the selector of every workload, so the
render fails when podLabels sets it. The rustfs-bucket-init Job is left
out, because a Job's pod template is immutable and a label change would
fail the upgrade.

The default render is unchanged, so manifests/ate-install/ stays as is.

Signed-off-by: QuentinBisson <quentin@giantswarm.io>
(cherry picked from commit 095ae30)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant