Files
homelab/terraform/longhorn.tf
T
Story Crater BotandClaude Haiku 4.5 e7f3409d0f feat(phase0): bootstrap External Secrets Operator and fix helmfile dual-ownership
Phase 0 groundwork for helmfile→ArgoCD migration:

1. Remove 3 bootstrap releases from helmfile (cert-manager, reloader, ingress-nginx)
   — already managed by terraform/bootstrap-releases.tf; eliminates dual-ownership

2. Bootstrap ESO (External Secrets Operator) as TF-managed release
   — required for all ExternalSecret resources in phases 1-3
   — added to bootstrap-releases.tf + helm-repositories.tf

3. Create ClusterSecretStore connecting ESO to Vault (K8s auth)
   — enables per-namespace/per-release secret injection
   — vault config documented in docs/PHASE0-ESO-VAULT-SETUP.md (manual setup)

4. Fix argocd-bootstrap.tf CA cert copy: use jq instead of sed for cleaner metadata handling

Changes:
- helmfile.yaml.gotmpl: remove cert-manager/reloader/ingress-nginx blocks
- terraform/bootstrap-releases.tf: add external-secrets release
- terraform/helm-repositories.tf: add external-secrets Helm repo
- k8s/external-secrets/clustersecretstore.yaml: ESO→Vault ClusterSecretStore
- k8s/argocd/apps/0-wave-0.yaml: stub wave 0 applications (schema fix, rewrite pending Phase 1)
- docs/PHASE0-ESO-VAULT-SETUP.md: manual ESO-Vault auth setup procedure

Next: Phase 1 will incrementally rewrite ArgoCD Applications + migrate helmfile releases.

Co-Authored-By: Claude Haiku 4.5 <[email protected]>
2026-07-15 14:53:16 -07:00

29 lines
1.1 KiB
Terraform

# Longhorn StorageClasses — app-specific variants only.
#
# The cluster-wide default `longhorn` SC is intentionally NOT managed here.
# It is owned by Longhorn's own setting-controller (reconciled from the
# `longhorn-storageclass` ConfigMap in longhorn-system, stamped with the
# `longhorn.io/last-applied-configmap` annotation). Managing it in Terraform
# caused a dual-ownership fight: TF strips the annotation, Longhorn re-adds it
# and delete+recreates the SC (params are immutable), racing TF's post-apply
# read ("Root object present, but now absent"). Longhorn recreates it
# automatically on any cluster, so it needs no TF representation.
resource "kubernetes_storage_class" "longhorn_kafka" {
metadata {
name = "longhorn-kafka"
}
storage_provisioner = "driver.longhorn.io"
reclaim_policy = "Delete"
allow_volume_expansion = true
volume_binding_mode = "Immediate"
parameters = {
numberOfReplicas = "3"
staleReplicaTimeout = "30"
fromBackup = ""
fsType = "ext4"
dataLocality = "disabled"
}
}