Skip to content

Two sources of truth for zxporter installer manifests #248

Description

@dray92

For what part of DevZero ZXporter you want to suggest a feature?

zxporter installer

DevZero ZXporter Version

Present on `main`

Use Case

Current installer approaches

  1. The "Static" Path (dist/)
  • Source: make build-installer calls helm template using the upstream prometheus-community/prometheus chart.
  • Config: It applies overrides from config/prometheus/hack.prometheus.values.yaml.
  • Result: dist/install.yaml is generated fresh from the upstream chart every time you run the make command.
  1. The "Helm" Path (helm-chart/zxporter)
  • Source: The zxporter chart does not depend on the upstream chart. Instead, it has manually embedded/vendored copies of the Prometheus manifests.
  • Evidence: helm-chart/zxporter/templates/ contains files like prometheus-deployments.yaml, prometheus-configmap.yaml, etc.
  • Result: When validatng/installing via Helm, it uses these local files, IGNORING the upstream chart and the hack values file.

The Problem (Split Brain)

Because the Helm chart uses a manual fork of the manifests while the make target uses the upstream chart:

Changes to hack.prometheus.values.yaml only affect dist/.
Changes to helm-chart/.../templates/ only affect Helm installs.
You must manually keep them in sync.

Attempted Solutions

both approaches work today, but seems like very easy to make mistakes.

Proposal

There are differences between the current dist/install.yaml (generated via Makefile) and the proposed helm template output. Key findings:

  • Missing Resources: The proposed Helm chart output is missing ClusterRoleBinding/devzero-zxporter-controller-manager (likely RBAC gap), Namespace (usually handled by helm install --create-namespace), and Secret (handled via values).
  • Naming Differences: PriorityClass (devzero-zxporter-devzero-zxporter-critical vs zxporter-critical) and Service (devzero-zxporter-controller-manager-mpa vs zxporter-mpa)
  • Missing Monitoring: missing RBAC for prometheus-kube-state-metrics?

Ultimately, we need to make it so that the helm chart is the source of truth (which is then used to generate stuff in dist/).

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions