Skip to content

radar-hub: podLabels and hub.installPodLabels - #62

Open
roylibman wants to merge 3 commits into
mainfrom
claude/radar-hub-pod-labels
Open

roylibman wants to merge 3 commits into
mainfrom
claude/radar-hub-pod-labels

Conversation

@roylibman

Copy link
Copy Markdown

Summary

Google Cloud Marketplace requires a goog-partner-solution label on every pod a partner product runs in the buyer's project. This lets a Self-Managed install set it, on the control plane's own pods and on the Radar agents the hub installs.

What changed

  • podLabels (top level): extra labels on the hub, web and bundled-Postgres pod templates. With hub.agent.enabled, also passed to the hub as HUB_AGENT_JOB_POD_LABELS (k=v,k=v), which puts them on the AI investigation Jobs it starts.
  • hub.installPodLabels: passed as HUB_INSTALL_POD_LABELS. The hub adds them to the Radar install commands it shows, so the agent in each connected cluster carries them.
  • Both env vars are emitted only when set, so an install that sets nothing renders exactly as before.
  • Schema: both use a shared definitions/labels with Kubernetes label syntax: propertyNames for keys, a pattern and 63-character limit for values. Non-string values are refused.
  • Selector keys refused: the template refuses the chart's own selector keys in podLabels (app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/component), which would otherwise duplicate a key or detach a pod from its controller.
  • README "Pod labels" section; values comments.
  • Staged as 1.15.0-rc.1, appVersion unchanged (1.14.1).

Release

The two env vars are read by a radar-hub release that includes skyhook-dev/radar-hub#356. Older hubs ignore them; podLabels on the chart's own pods works on any hub. Per this repo's release rules, merging publishes a chart version; promote to 1.15.0 final with an appVersion that includes that Hub change.

Testing

tests/render-matrix.sh (new "pod labels" block: labels on all three pod templates at the pod-template level, absent by default, selector key, non-string, bad value and bad key refused, prefixed key accepted, both env vars wired and absent when unset), .github/ci/agent-test.sh (58 assertions) and helm lint pass locally on Helm 4.2. CI runs the matrix on Helm 3.14.

🤖 Generated with Claude Code

roylibman and others added 2 commits October 27, 2026 18:30
podLabels adds labels to the hub, web and bundled Postgres pods, and (as
HUB_AGENT_JOB_POD_LABELS) to the AI investigation Jobs the hub starts.
hub.installPodLabels (HUB_INSTALL_POD_LABELS) adds labels to the Radar
install commands the hub shows. Both exist for Google Cloud Marketplace
consumption tracking, which needs a goog-partner-solution label on every
pod in the customer's project.

The schema enforces Kubernetes label syntax, and the chart refuses its own
selector keys in podLabels. Staged as 1.15.0-rc.1 with appVersion unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…keys

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@cursor

cursor Bot commented Oct 28, 2026

Copy link
Copy Markdown

Bugbot needs on-demand usage enabled

Bugbot uses usage-based billing for this team and requires on-demand usage to be enabled.

A team admin can enable on-demand usage in the Cursor dashboard.

@qodo-free-for-open-source-projects

Copy link
Copy Markdown

PR Summary by Qodo

Add pod labels to Radar Hub and generated agent installs

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

Grey Divider

AI Description

• Add configurable pod labels for Hub, web, bundled Postgres, investigation Jobs, and generated
 agent installs.
• Validate label syntax and reject selector-label overrides to protect pod-controller matching.
• Document Marketplace configuration and test rendering, validation, and default behavior.
Diagram

graph TD
  Values["Label values"] --> Schema["Shared schema"] --> Templates["Helm templates"] --> Pods["Chart pods"]
  Templates --> HubEnv["Hub environment"] --> Jobs["Investigation Jobs"]
  HubEnv --> Commands["Install commands"] --> Agents["Radar agents"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Cluster-wide admission labeling
  • ➕ Could label pods without changing individual chart templates.
  • ➖ Requires policy in every relevant cluster and does not convey labels through Hub-generated install commands.
2. Single label setting for all pod types
  • ➕ Reduces duplicate Marketplace label configuration.
  • ➖ Prevents operators from setting different labels on control-plane pods and connected-cluster agents.

Recommendation: Keep the two chart settings and optional Hub environment variables. This labels chart-owned pods directly while preserving independent control over connected-cluster agents; admission policy cannot reliably cover both paths. Promote the final chart only with a Hub appVersion that supports the new variables.

Files changed (9) +135 / -2

Enhancement (5) +73 / -1
_helpers.tplAdd reusable label rendering and serialization helpers +31/-0

Add reusable label rendering and serialization helpers

• Renders additional pod-template labels while refusing the chart's selector keys. Serializes label maps into comma-separated key=value strings for Hub environment variables.

charts/radar-hub/templates/_helpers.tpl

deployment-hub.yamlLabel Hub pods and pass labels to Hub features +16/-0

Label Hub pods and pass labels to Hub features

• Adds podLabels to the Hub pod template. Emits HUB_INSTALL_POD_LABELS for generated agent installs and, when the Hub agent is enabled, HUB_AGENT_JOB_POD_LABELS for investigation Jobs; both remain absent when unset.

charts/radar-hub/templates/deployment-hub.yaml

deployment-web.yamlAdd labels to web pod templates +3/-0

Add labels to web pod templates

• Applies podLabels to the web Deployment's pod template without changing its selector labels.

charts/radar-hub/templates/deployment-web.yaml

postgres-bundled.yamlAdd labels to bundled Postgres pod templates +3/-0

Add labels to bundled Postgres pod templates

• Applies podLabels to the bundled Postgres StatefulSet's pod template without changing its selector labels.

charts/radar-hub/templates/postgres-bundled.yaml

values.schema.jsonDefine shared validation for both label settings +20/-1

Define shared validation for both label settings

• Adds podLabels and hub.installPodLabels as references to one label-map definition. The definition constrains key syntax and requires string values matching the configured label-value pattern.

charts/radar-hub/values.schema.json

Tests (1) +21 / -0
render-matrix.shCover pod-label rendering and invalid configurations +21/-0

Cover pod-label rendering and invalid configurations

• Checks labels at each pod-template location, both Hub environment variables, and their absence by default. Also checks rejection of reserved keys, non-string or invalid labels, and overlong values, plus acceptance of a prefixed key.

charts/radar-hub/tests/render-matrix.sh

Documentation (1) +24 / -0
README.mdDocument pod-label settings and Marketplace usage +24/-0

Document pod-label settings and Marketplace usage

• Explains which pods receive each setting, shows the Google Cloud Marketplace label configuration, and notes selector-key restrictions and Hub-version compatibility.

charts/radar-hub/README.md

Other (2) +17 / -1
Chart.yamlStage chart version 1.15.0-rc.1 +1/-1

Stage chart version 1.15.0-rc.1

• Bumps the chart version while leaving appVersion at 1.14.1. The default Hub image therefore remains unchanged.

charts/radar-hub/Chart.yaml

values.yamlExpose optional pod-label settings +16/-0

Expose optional pod-label settings

• Adds empty defaults for podLabels and hub.installPodLabels. Comments explain their distinct destinations, Marketplace use, selector-key restrictions, and Hub-version requirement.

charts/radar-hub/values.yaml

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Oct 28, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. Agent installs fail on selector labels ✓ Resolved
Description
hub.installPodLabels accepts and forwards app.kubernetes.io/name and
app.kubernetes.io/instance without the selector-key check applied to podLabels. When either key
is set to a value that differs from the Radar chart's selector, the generated install command passes
a label that conflicts with the agent Deployment's pod selector.
Code

charts/radar-hub/values.schema.json[R204-206]

+        "installPodLabels": {
+          "$ref": "#/definitions/labels"
+        },
Evidence
The new schema uses the unrestricted labels definition, and the environment variable serializes
every entry. The documented destination is the Radar install command; the Radar chart appends
podLabels to a template whose selector labels are fixed.

charts/radar-hub/values.schema.json[204-206]
charts/radar-hub/templates/deployment-hub.yaml[395-400]
charts/radar-hub/README.md[166-170]
charts/radar/templates/deployment.yaml[91-112]
charts/radar/templates/_helpers.tpl[43-48]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hub.installPodLabels` accepts labels that conflict with the Radar agent Deployment's fixed pod selector.
## Fix Focus Areas
- charts/radar-hub/values.schema.json[204-206]
- charts/radar-hub/templates/deployment-hub.yaml[398-400]
- charts/radar/templates/deployment.yaml[103-112]
## Recommended Fix
Reject the Radar chart's selector keys in `hub.installPodLabels` before emitting the environment variable, and add a render test for each rejected key.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Long label prefixes block pod creation ✓ Resolved
Description
The key pattern in definitions.labels has no length limit on the DNS prefix before /. A
podLabels key with a prefix longer than Kubernetes' 253-character DNS-subdomain limit passes chart
validation and is rendered into each enabled pod template, which the cluster then rejects.
Code

charts/radar-hub/values.schema.json[R829-830]

+      "propertyNames": {
+        "pattern": "^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?[A-Za-z0-9]([-A-Za-z0-9_.]{0,61}[A-Za-z0-9])?$"
Evidence
The prefix portion of the new regex uses an unbounded *, and both chart label settings reference
this definition. The pod-label helper emits accepted keys into the Hub, web and bundled-Postgres pod
templates.

charts/radar-hub/values.schema.json[814-816]
charts/radar-hub/values.schema.json[825-835]
charts/radar-hub/templates/_helpers.tpl[48-57]
charts/radar-hub/templates/deployment-hub.yaml[23-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The label-key regex accepts DNS prefixes longer than Kubernetes permits, so chart validation can accept an unusable pod label.
## Fix Focus Areas
- charts/radar-hub/values.schema.json[826-835]
- charts/radar-hub/tests/render-matrix.sh[453-458]
## Recommended Fix
Add a schema constraint that limits the prefix before `/` to 253 characters while retaining the existing name checks. Add a test that rejects a key with a 254-character prefix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Tip of the day
💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread charts/radar-hub/values.schema.json Resolved
Comment thread charts/radar-hub/values.schema.json Resolved
…prefixes

hub.installPodLabels go on every Radar agent's pod template, so the agent
chart's selector keys (app.kubernetes.io/name, app.kubernetes.io/instance)
are refused there, as the chart's own are in podLabels. Label keys' prefix is
capped at Kubernetes' 253 characters.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
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