For what part of DevZero ZXporter you want to suggest a feature?
zxporter installer
DevZero ZXporter Version
Use Case
Current installer approaches
- 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.
- 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
For what part of DevZero ZXporter you want to suggest a feature?
zxporterinstallerDevZero ZXporter Version
Present on `main`Use Case
Current installer approaches
dist/)make build-installercalls helm template using the upstreamprometheus-community/prometheus chart.config/prometheus/hack.prometheus.values.yaml.dist/install.yamlis generated fresh from the upstream chart every time you run themakecommand.helm-chart/zxporter)zxporterchart does not depend on the upstream chart. Instead, it has manually embedded/vendored copies of the Prometheus manifests.helm-chart/zxporter/templates/contains files likeprometheus-deployments.yaml,prometheus-configmap.yaml, etc.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.yamlonly affectdist/.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 proposedhelm templateoutput. Key findings:ClusterRoleBinding/devzero-zxporter-controller-manager(likely RBAC gap), Namespace (usually handled byhelm install --create-namespace), and Secret (handled via values).devzero-zxporter-devzero-zxporter-criticalvszxporter-critical) and Service (devzero-zxporter-controller-manager-mpavszxporter-mpa)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