azure: aks_route_table and vnet fight over the subnet's routeTable, so the stack never converges

[gdrojas]

Symptom

An Azure stack using infrastructure/azure/vnet + infrastructure/azure/aks + infrastructure/azure/aks_route_table never reaches No changes. Every plan, forever:

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

Applying it succeeds and leaves the cluster healthy — the route table ends up correctly attached — but the very next plan is byte-identical. Verified by applying and immediately re-planning:

$ tofu apply -auto-approve
Apply complete! Resources: 2 added, 1 changed, 2 destroyed.

$ tofu plan
Plan: 2 to add, 1 to change, 2 to destroy.     # unchanged

Root cause — two modules own the same field

1. vnet wants to remove the route table. The AVM subnet resource manages the whole request body, and nothing in its config mentions a route table, so every plan proposes:

# module.vnet...azapi_resource.subnet[0] will be updated in-place
  ~ properties = {
      ~ routeTable = {
          - id = ".../MC_<rg>_<cluster>_<region>/.../routeTables/aks-agentpool-...-routetable"
        } -> null

That route table is created by AKS itself for kubenet clusters, after the vnet exists, so the vnet module has no way to know about it.

2. aks_route_table re-attaches it unconditionally. From infrastructure/azure/aks_route_table/main.tf:7:

triggers_replace = timestamp()

timestamp() differs on every plan, so terraform_data.trigger always replaces, and azapi_update_resource.aks_subnet_route_table follows it through replace_triggered_by.

The two cancel out on every apply and reset for the next one.

Why it matters

• The stack can never be used as a convergence check. Real drift is indistinguishable from this permanent noise, which is precisely how an unrelated bug went unnoticed for us: a stale registry hostname sat in a plan nobody could read as clean.
• Every apply detaches and re-attaches the route table on a live kubenet cluster. It is brief, but pod-to-pod traffic across nodes degrades in that window — a recurring cost paid on every unrelated change.

Suggested direction

Fixing only the trigger is not enough: even with a stable trigger, vnet still proposes routeTable -> null on every plan. Both halves need to move.

1. aks_route_table — derive triggers_replace from the values that actually matter (subnet id + route table id) instead of timestamp(), so it re-runs only when the attachment really changes.
2. vnet — stop fighting for the field: either expose a per-subnet route_table input, or add lifecycle { ignore_changes = [...routeTable] } on the subnet so an externally-managed route table survives.

Happy to send the PR once you decide which shape you prefer for (2) — exposing the input is cleaner but needs the id up front, which is awkward because AKS only creates the route table after the cluster comes up.

Environment

tofu-modules v6.8.1 · AKS kubenet (podCidr 10.244.0.0/16) · OpenTofu with azapi + azurerm.

[gdrojas]

Correction: timestamp() is the mitigation, not the bug

I mischaracterised this above. Removing the timestamp trigger on its own would make things worse, not better.

Order of operations inside a single apply:

1. module.vnet updates the subnet and writes routeTable = null — the AVM subnet submodule always renders the field, so a null input is an explicit detach, not an omission:

   routeTable = var.route_table != null ? { id = var.route_table.id } : null

2. module.aks_route_table re-attaches it.

triggers_replace = timestamp() is what guarantees step 2 runs every time step 1 does. With a stable trigger it would stop firing, the detach in step 1 would stand, and the kubenet cluster would lose pod-to-pod routing across nodes. So the loop is a deliberate workaround for the detach, and the detach is the actual defect.

Where the fix belongs

The AVM subnet submodule already accepts the field:

variable "route_table" {
  type    = object({ id = string })
  default = null
}

infrastructure/azure/vnet just never plumbs it through. If it did, the subnet would declare the route table it actually has, stop proposing null, and aks_route_table would no longer be needed.

The wrinkle is ordering: AKS creates the route table only after the cluster exists, and the cluster needs the subnet — so the id cannot be known on a first apply, and wiring it directly is a cycle.

Sending a PR that makes the passthrough possible (optional, defaults to null, no change for current consumers). That unblocks the real fix without forcing a decision on how consumers should resolve the id — which is the part that still needs your call.

[gdrojas]

PR #493 con la mitad #1 (trigger estable en vez de timestamp()). La mitad #2 (el vnet dejando de proponer routeTable -> null) ya está en main vía el passthrough route_table en subnets_definition (#475). Con el passthrough el stack converge sin attach separado; #493 arregla aks_route_table para los casos que aún lo usen. Verificado en la demo: con el passthrough (dropping aks_route_table) el stack azure llega a No changes.