Migrate node-red storage to Longhorn

[Copilot]

Node-red's PVC had no explicit storage class (falling back to the cluster default / NFS-backed). This migrates it to Longhorn, consistent with esphome, home-assistant-dad, and other home-automation workloads.

Changes

• pvc.yaml (new): declares node-red-data-longhorn — 1Gi, storageClass: longhorn, ReadWriteOnce
• pvc-nfs.yaml (new): explicitly manages the legacy node-red-data NFS PVC with helm.sh/resource-policy: keep, preventing Helm from deleting it during the upgrade when existingClaim is set
• helmrelease.yaml:
  • nodeSelector: storage: longhorn — pins pod to Longhorn-capable nodes
  • persistence.data.existingClaim: node-red-data-longhorn — uses pre-created Longhorn PVC
  • additionalVolumes — exposes old node-red-data NFS PVC to the init container without mounting it in the main container
  • initContainers: data-migration — one-shot busybox:1.36.1 container that cp -as from old NFS volume to new Longhorn volume; idempotent (skips if destination is non-empty)
• kustomization.yaml: adds pvc.yaml and pvc-nfs.yaml to resources; snapshots.yaml removed as Longhorn handles snapshots automatically for all volumes
• .github/workflows/render-helm-templates.yaml (new): renders both the base-branch and PR-branch versions of any changed helmrelease*.yaml and posts a unified diff to the GitHub Step Summary, so the resulting Kubernetes manifests can be reviewed before merging

Migration flow

init container (data-migration)
  /old-data  ← node-red-data       (legacy NFS PVC, read-only)
  /new-data  ← node-red-data-longhorn (Longhorn PVC)
  cp -a /old-data/. /new-data/   # runs once; skipped on subsequent boots

main container
  /data      ← node-red-data-longhorn

Once the migration is confirmed successful the init container, additionalVolumes entry, and the old node-red-data PVC (along with pvc-nfs.yaml) can be cleaned up.

[jeffborg]

We don't need the snapshot job longhorn does this Automatically for all

[Copilot]

We don't need the snapshot job longhorn does this Automatically for all

Removed snapshots.yaml and dropped it from kustomization.yaml in e2fb2d9.

[jeffborg]

This will cause the existing nfs pvc to be destroyed

[Copilot]

Good catch. When existingClaim is set, Helm removes the old PVC from its managed resource set and will delete it on the next helm upgrade. Fixed in 5f4f426 by adding pvc-nfs.yaml — a Kustomize-managed declaration of the node-red-data PVC with helm.sh/resource-policy: keep, which prevents Helm from deleting it during the upgrade. Flux's kustomize-controller will apply this annotation before Helm reconciles.

[jeffborg]

Copy across from the other unmerged pr the helm diff tool. I'm not sure this is going to work without seeing the rendered output

[Copilot]

Copy across from the other unmerged pr the helm diff tool. I'm not sure this is going to work without seeing the rendered output

Added in d9027b9. The workflow (copied from PR #2532) is now live on this PR — it triggers on any helmrelease*.yaml change, renders both the base and PR versions using the existing render_template.sh, and posts a unified diff to the GitHub Step Summary so you can see the exact Kubernetes manifest changes before merging.

[jeffborg]

Helm render fails

[Copilot]

Helm render fails

Fixed in fd30db2. The k8s-at-home common chart library expects initContainers to be a map (keyed by container name), not a list — changed from - name: data-migration (list) to data-migration: (map key). The render workflow will re-run on this commit and should pass now.