HyperDX Dashboard Provisioner

[ZeynelKoca]

Summary

• Add dashboard provisioning via k8s-sidecar that discovers ConfigMaps labeled hyperdx.io/dashboard: "true" across all namespaces
• k8s-sidecar writes dashboard JSON to a shared volume, HyperDX upserts them natively
• Dashboards matched by name for idempotency (update existing, create new, never delete)
• Two ways to provide dashboards: inline in values or via labeled ConfigMaps from any namespace

Design decisions

• k8s-sidecar + native HyperDX provisioner: Sidecar handles ConfigMap discovery (same pattern as Grafana). HyperDX handles MongoDB upsert natively
• ClusterRole: Needed for cross-namespace ConfigMap discovery.

Dependencies

• Requires feat: Add file-based dashboard provisioner hyperdxio/hyperdx#1962

[changeset-bot]

🦋 Changeset detected

Latest commit: d0f332d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
helm-charts	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[ZeynelKoca]

Implements feature request #170

[heiba]

@dhable Can we please look at this PR and see how we can progress it ?

[ZeynelKoca]

As per PR description, I redesigned the initial implementation to handle upsert behavior natively through hyperdx (same pattern as Grafana). This PR is dependent on hyperdxio/hyperdx#1962

[dhable]

Thank you for following up the feature change with a helm change as well. Great to keep these two up-to-date.

I think the need to provision RBAC roles and scan for tagged config maps is more than our typical users would expect from an application install. Using the default ConfigMap functionality to mount the dashboard data as a file would avoid the need for an additional service account, RBAC, etc.

[ZeynelKoca]

Thank you for following up the feature change with a helm change as well. Great to keep these two up-to-date.

I think the need to provision RBAC roles and scan for tagged config maps is more than our typical users would expect from an application install. Using the default ConfigMap functionality to mount the dashboard data as a file would avoid the need for an additional service account, RBAC, etc.

No worries, the dashboard provisioning would be really nice for us as we're planning to go into production with clickstack soon and implementing missing features is faster than creating an issue 😄

Ready for another review!

[ZeynelKoca]

@dhable Gentle bump. Happy to hear your thoughts on the implementation

[tincann]

@dhable it would be great if this feature could be released! Very handy.

[github-actions]

Deep Review

✅ No critical issues found.

The dashboard-provisioning feature is well-constructed and unusually well-tested (~950 lines of new helm-unittest coverage). RBAC is safe-by-default: dashboards.enabled=false renders nothing; enabling with namespaces: [] produces only a namespaced Role/RoleBinding; cluster-wide access requires an explicit, case-sensitive [ALL] sentinel that validateDashboards refuses to combine with named namespaces. Watched scope (NAMESPACE env) and granted scope (Role vs ClusterRole) derive from the same helpers, so they cannot drift. No secrets are introduced.

🟡 P2 — recommended

• charts/clickstack/templates/hyperdx/deployment.yaml:395 — The dashboard-watcher is a plain container with no readiness probe, so when it CrashLoops (e.g. rbac.create=false with no out-of-band grant → 403) the pod goes NotReady and the healthy HyperDX app is dropped from its Service endpoints — an app-wide availability regression triggered by an auxiliary component.
  • Fix: Run the watcher as a native sidecar (initContainers entry with restartPolicy: Always) so its failures don't gate app readiness; this also removes the first-boot ordering race where the app reads an empty /dashboards before the watcher populates it.
  • _reliability

🔵 P3 nitpicks (4)

• charts/clickstack/templates/hyperdx/deployment.yaml:397 — The dashboard-watcher container omits imagePullPolicy while the app container sets one, an inconsistency that leans on the cluster default for the pinned tag.

  • Fix: Add an imagePullPolicy to the watcher container to match the app container.

• charts/clickstack/templates/_helpers.tpl:122 — validateDashboards is invoked only from deployment.yaml, and dashboardsClusterWide uses exact has "ALL" while validation trims/uppercases, so rendering an individual dashboard template in isolation (e.g. helm template --show-only templates/hyperdx/dashboard-provisioner-rbac.yaml) bypasses validation and can emit a RoleBinding targeting an invalid namespace; a full helm install always renders deployment.yaml so validation fires normally.

  • Fix: Include clickstack.hyperdx.validateDashboards at the top of dashboard-provisioner-rbac.yaml and dashboard-configmap.yaml too, and derive dashboardsClusterWide from trimmed values so the sentinel check matches validation.
  • _{correctness, adversarial}

• charts/clickstack/values.yaml:1464 — The default watcher memory limit (64Mi) is likely to OOMKill under namespaces: [ALL] cluster-wide discovery on large clusters; the risk is noted in a comment but the shipped default is unchanged.

  • Fix: Consider raising the default memory limit when cluster-wide, or emit a NOTES hint to bump resources on the [ALL] path.

• charts/clickstack/tests/dashboard-provisioner_test.yaml:855 — Coverage gaps for new branches: serviceAccount.create: true combined with dashboards, rbac.create: false combined with [ALL]/multi-namespace scope, and no single test tying the watcher NAMESPACE env to the emitted RoleBinding namespace set for one value set.

  • Fix: Add these cases so a future edit that desyncs granted scope from watched scope, or the explicit-create SA branch, is caught.
  • _{testing, correctness}

---

Reviewers (7): correctness, security, reliability, adversarial, testing, maintainability, project-standards.

Testing gaps:

• helm-unittest cannot verify the sidecar actually discovers ConfigMaps or that the app consumes DASHBOARD_PROVISIONER_* env at runtime — an integration-tests/ suite installing with dashboards enabled and RBAC scoped to a second namespace would close this.
• No test asserts pod-level Ready behavior when the watcher CrashLoops (rbac.create=false path).