chore(cf-tunnels): drop cluster_apps resource — operator owns it#3
Merged
chore(cf-tunnels): drop cluster_apps resource — operator owns it#3
Conversation
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.
OpenTofu Plan |
3 tasks
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)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
cloudflare_zero_trust_tunnel_cloudflared.cluster_appsresource was a stub that held the import-time tunnel ID underlifecycle { ignore_changes = all }— it didn't actually manage anything. The real owner of that tunnel is nowcloudflare-operator, via theClusterTunnelCR inkustomize-cluster/operators/cloudflare/cluster-tunnel.yaml.This drops the dead resource block plus its (unused)
tunnel_ids.cluster_appsoutput.Important — operator action required before `apply`
The resource is still in this root's TF state pointed at the legacy
cluster-apps-crctunnel ID1ac3a39c-7d97-422e-88e5-1f82b6334bbb. After merge, the operator must pick one of:Option 1 — preserve the legacy tunnel in Cloudflare (just stop tracking it):
Then
tofu planis clean, no resources change. Delete the orphan tunnel manually from the Cloudflare dashboard whenever convenient.Option 2 — let TF destroy the legacy tunnel:
TF will destroy
1ac3a39c-…(the orphan). Safe because no DNS records or active workloads reference it — the new operator-managed tunnelcluster-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
tofu planshows no changes🤖 Generated with Claude Code