Terraform variable reference#

This is the supported way to reach chart settings the module does not model — including scheduling (node selectors, tolerations) and Grafana ingress, neither of which the module surfaces yet. See the README.

Leave null, which is the supported path: the module reads the version out of the chart’s own Chart.yaml in this repository, so a module ref always installs the chart it shipped with and the two cannot drift. Set it only to pin a chart version different from the module’s.

Set false when the cluster already has them from elsewhere — kube-prometheus-stack, or a platform team that owns CRDs centrally — since Terraform would otherwise fail trying to create objects it does not own.

Note the teardown blast radius: destroying this release deletes the CRDs, which cascades to every GrafanaDashboard, GrafanaDatasource, PrometheusRule, and PodMonitor in the cluster, including ones this stack did not create. It is a separate helm_release so it can be targeted independently (-target=module.monitoring.helm_release.crds).

Teardown also needs the Grafana custom resources deleted before grafana-operator goes, or their finalizers have no remover and the CRDs wedge in Terminating. See the “Uninstalling” page in the docs.

Off by default. The chart enables it with an empty password, and no mz_support role is provisioned by the Materialize Terraform modules, so it would come up failing authentication. It also targets the legacy metric surface that native endpoints are replacing.

Supply sql_scraper_password when enabling it.

min_importance picks a metric tier — essential, recommended, extended, diagnostic, or all — and each tier includes the ones below it. This is a cost control: GCM bills per custom metric and all sends the entire surface.

Authentication is ADC only. Bind the gateway ServiceAccount to a Google service account holding roles/monitoring.metricWriter through object_storage.gateway_service_account_annotations; failing that it falls back to the node’s service account, which works only if that account has the role.

Leave false when the Materialize operator module installs it (the default topology), and set it true when that module has install_metrics_server = false — otherwise nothing provides the metrics API and the Materialize Console silently loses cluster metrics.

Not applied to the Alloy agent: it is a DaemonSet that must reach every node to collect logs and node metrics, so constraining it to a workload pool would silently stop collection everywhere else.

cloud selects the objstore dialect. The *_service_account_annotations maps carry the workload-identity annotation for each component’s ServiceAccount — the chart validates that the annotation’s cloud matches the objstore backend, so a mismatched pair fails at render time rather than at pod start.

azure_storage_account is required when cloud is azure, and only then: both Loki and Thanos name the account separately from the container. Azure needs nothing else — the annotation plus the pod label the module applies are all the Entra webhook requires.

Profiles are read from the chart directory in this repository at the same commit as the pinned chart version, so they cannot drift from it. A profile that does not exist yet is skipped, which is how Thanos sizing will start applying once those profiles land.

Required where the default class cannot serve the nodes: GCP’s C4 and N4 families take only Hyperdisk, and every Persistent Disk class fails to attach with pd-balanced disk type cannot be used by <machine-type>.

Changing it on an existing install does not move the volumes. volumeClaimTemplates are immutable, so the old PVCs must be deleted first — discarding their contents.