Skip to content

chore(cf-tunnels): drop cluster_apps resource — operator owns it#3

Merged
xnoto merged 2 commits intomainfrom
chore/cluster-apps-tunnel-cleanup
Apr 30, 2026
Merged

chore(cf-tunnels): drop cluster_apps resource — operator owns it#3
xnoto merged 2 commits intomainfrom
chore/cluster-apps-tunnel-cleanup

Conversation

@xnoto
Copy link
Copy Markdown
Contributor

@xnoto xnoto commented Apr 30, 2026

Summary

The cloudflare_zero_trust_tunnel_cloudflared.cluster_apps resource was a stub that held the import-time tunnel ID under lifecycle { ignore_changes = all } — it didn't actually manage anything. The real owner of that tunnel is now cloudflare-operator, via the ClusterTunnel CR in kustomize-cluster/operators/cloudflare/cluster-tunnel.yaml.

This drops the dead resource block plus its (unused) tunnel_ids.cluster_apps output.

Important — operator action required before `apply`

The resource is still in this root's TF state pointed at the legacy cluster-apps-crc tunnel ID 1ac3a39c-7d97-422e-88e5-1f82b6334bbb. After merge, the operator must pick one of:

Option 1 — preserve the legacy tunnel in Cloudflare (just stop tracking it):

tofu state rm cloudflare_zero_trust_tunnel_cloudflared.cluster_apps

Then tofu plan is clean, no resources change. Delete the orphan tunnel manually from the Cloudflare dashboard whenever convenient.

Option 2 — let TF destroy the legacy tunnel:

tofu apply

TF will destroy 1ac3a39c-… (the orphan). Safe because no DNS records or active workloads reference it — the new operator-managed tunnel cluster-apps-k3s (created by the kustomize-cluster ClusterTunnel CR) gets a fresh ID and the operator reconciles DNS to point at it.

Either is fine. Option 2 is tidier; Option 1 is the cautious choice if you want to verify the new tunnel is fully serving traffic before retiring the orphan.

Test plan

  • After merge + chosen apply path: tofu plan shows no changes
  • No regressions on already-working FQDNs (e.g., warp connector unaffected)

🤖 Generated with Claude Code

The cluster-apps Cloudflare Tunnel is created and managed by
cloudflare-operator's ClusterTunnel CR (see
kustomize-cluster/operators/cloudflare/cluster-tunnel.yaml). The
Terraform resource block was a stub left over from manual import — it
held the import-time tunnel ID under ignore_changes=all, so it never
actually managed the tunnel.

Removing the block also drops cluster_apps from outputs.tf; nothing
outside this repo consumed tunnel_ids.cluster_apps.
@xnoto xnoto self-assigned this Apr 30, 2026
@xnoto xnoto closed this Apr 30, 2026
@xnoto xnoto reopened this Apr 30, 2026
@xnoto xnoto merged commit fd9148f into main Apr 30, 2026
4 checks passed
@xnoto xnoto deleted the chore/cluster-apps-tunnel-cleanup branch April 30, 2026 01:39
@github-actions
Copy link
Copy Markdown

OpenTofu Plan

OpenTofu will perform the following actions:

  # cloudflare_zero_trust_tunnel_cloudflared.cluster_apps will be destroyed
  # (because cloudflare_zero_trust_tunnel_cloudflared.cluster_apps is not in configuration)
  - resource "cloudflare_zero_trust_tunnel_cloudflared" "cluster_apps" {
      - account_id        = (sensitive value) -> null
      - account_tag       = "03f750691b4ad4d59aa4b7205adaa108" -> null
      - config_src        = "local" -> null
      - connections       = [] -> null
      - conns_inactive_at = "2026-02-21T03:38:29Z" -> null
      - created_at        = "2025-12-31T18:14:55Z" -> null
      - id                = "1ac3a39c-7d97-422e-88e5-1f82b6334bbb" -> null
      - metadata          = jsonencode({})
      - name              = "cluster-apps" -> null
      - remote_config     = false -> null
      - status            = "down" -> null
      - tun_type          = "cfd_tunnel" -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Changes to Outputs:
  ~ tunnel_ids = {
      - cluster_apps = "1ac3a39c-7d97-422e-88e5-1f82b6334bbb"
        # (1 unchanged attribute hidden)
    }

xnoto added a commit that referenced this pull request Apr 30, 2026
## Summary

The cloudflare-operator owns the `cluster-apps` tunnel and configures
the cloudflared deployment to route hostnames it sees in
`TunnelBinding`s — but it does not write DNS records. Without a CNAME
pointing each FQDN at `<tunnel-id>.cfargotunnel.com`, requests reach
Cloudflare's edge but error out with 530 / 1033 (no tunnel route for
hostname).

This PR:
- Adds a `data "cloudflare_zero_trust_tunnel_cloudflared"
"cluster_apps"` lookup by name (`cluster-apps-k3s`) so the tunnel ID
resolves at plan time without being hard-coded in TF
- Adds a `for_each` `cloudflare_dns_record` covering `argocd`,
`grafana`, `status`, `ansible` — the hostnames declared in
TunnelBindings under `kustomize-cluster/workloads/`

If the operator ever recreates the tunnel, the next `tofu plan` picks up
the new ID via the data source and updates the CNAME content.

## Test plan

- [x] \`tofu plan\` shows 4 CNAMEs created, no other drift
- [x] After apply: \`curl -I https://argocd.makeitwork.cloud\` returns
ArgoCD's login HTML (not Cloudflare 530)
- [x] After grafana / ansible / status workloads come up (Phase B),
their FQDNs resolve too

## Pairs with

- The operator-managed tunnel naming was set in kustomize-cluster #8
(`cluster-apps-k3s`).
- The previous tunnel cleanup is in tfroot-cloudflare #3.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant