Epic: GitOps-native install & declarative management

Epic for making Fission a first-class citizen of declarative, pipeline-driven platform management: install it, upgrade it, and manage every function on it from Git, with no imperative side-channels.

Why this epic

This is the largest cluster of reactions in the open backlog — a set of issues that are all the same complaint from different angles: Fission assumes a human with a CLI, but 2026 platform teams deploy through Argo/Flux/Terraform and expect everything to be a manifest.

• #2382 — Include CRDs in Helm Chart — 12 reactions. CRDs install out-of-band (kubectl create -k crds/v1 / make create-crds), which breaks single-shot Helm/Argo/Flux installs and version-skews CRDs against the chart.
• #1907 — Terraform template support — 12 reactions. No IaC story for Fission objects.
• #2383 — Allow file contents inline in values.yaml (8 reactions) — Kafka TLS certs can't be supplied without unpacking the chart.
• #1687 — Kubectl Apply for Fission Specs (7 reactions) — users want plain kubectl apply/GitOps for what fission spec apply does.
• #2906 — Use .Release.Name as prefix for resources / #2835 — multiple instances per cluster.
• #2742 — Fission Operator — manage Fission itself via CRDs.
• #2928 — Package build trigger mechanism (esp. with GitOps) — when specs are applied from Git, rebuilds must trigger from content change, not CLI invocation.
• #740 (closed → folded here) — the surviving half is spec apply --set templating.

Plus the long tail of fission spec correctness/UX issues that erode pipeline trust: #543 (rename handling), #551 (duplicate archive names), #555 (--watch vs builder conflicts), #623 (empty ArchiveUploadSpec validation), #1037/#1574 (scaffolding), #1491 (misleading duplicate-resource error), #3230 (spec-file defaulting diverges from CLI), #3296 (false-positive duplicate detection on reapply).

The strategic observation

The hard blocker for "just kubectl apply everything" was always the package archive: a Function references a Package whose archive lives in storagesvc, uploaded imperatively by the CLI — un-GitOps-able by construction. That blocker has quietly dissolved:

• RFC-0001/0012 (shipped, default cold-start path): a package can be an OCI image reference — content-addressed, built in the user's own CI, pushed to their registry. No storagesvc upload step, nothing imperative left.
• Functions, Environments, Triggers, Workflows, aliases are already plain CRDs with a validating webhook.
• The webhook + status conditions (RFC-0004/0013 work) give GitOps controllers real health signals to sync against.

So the declarative path doesn't need to be built — it needs to be completed, blessed, and documented as the primary path, with fission spec repositioned as a scaffolding/DX layer on top of plain CRDs rather than a parallel state-management system.

What "done" looks like

1. helm install fission is complete — CRDs delivered and upgraded by the chart (Helm's crds/ dir doesn't upgrade; needs the templated-CRDs-or-SSA-hook decision), cert/file contents inlinable via values (#2383), all resources release-name-prefixed so two installs coexist (#2906, #2835).
2. A blessed plain-CRD workflow: docs + examples for Argo/Flux managing Functions/Envs/Triggers directly, with OCI-image packages so no imperative upload exists; Package build lifecycle driven by content hash (#2928) so a Git push → new image/archive → rebuild happens without the CLI.
3. fission spec demoted to DX layer and made pipeline-safe: idempotent reapply (#3296, #1491), rename semantics (#543), validation (#551, #623), templating (--set, from #740), defaulting parity with the CLI (#3230).
4. IaC integrations: a Terraform provider (or, minimum viable: documented kubernetes_manifest patterns + examples generated from the CRD schemas) (#1907); optionally a FissionInstance operator direction (#2742) — to be scoped in the RFC, possibly out.

Sub-issues

• #2382 — CRDs in the Helm chart (install + upgrade path)
• #2383 — file contents inline in values.yaml
• #2906 / #2835 — release-name prefixing / multiple instances per cluster
• #1687 — blessed kubectl-apply/GitOps path for Fission objects
• #2928 — content-driven package rebuilds under GitOps
• #1907 — Terraform/IaC support
• #2742 — operator direction (scope decision in the RFC)
• fission spec pipeline-safety batch: #543, #551, #555, #623, #1037, #1491, #1574, #3230, #3296
• spec apply --set templating (from #740)

Next step

An RFC (working number RFC-0029, GitOps-native install and declarative management) is being drafted covering: the CRD delivery/upgrade mechanism, chart packaging changes, the plain-CRD + OCI-package golden path, the spec-tool contract, and the IaC surface. It will be linked here for review.