Template VM always changes states

[tico88612]

I'm not sure this is indentation behavior, so I post the discussion.

I applied a template VM, but when I tried another apply, it gave me ipv4_addresses, ipv6_addresses, network_interface_names known after apply.

My current solution is to add lifecycle ignore_changes, but it pops up a warning. Warning: Redundant ignore_changes element

  lifecycle {
    ignore_changes = [ipv4_addresses, ipv6_addresses, network_interface_names]
  }

[ylbeethoven]

I think this is expected behavior for computed attributes. Ideally the provider should ignore these attributes when template = true.

[tico88612]

Yeah, I hope this should ignore when template = true

[bpg]

Having attributes "known after apply" is completely normal for computed attributes, and shouldn't cause any issues.
From the terraform perspective, the attribute is computed, regardless if template flag is set or not. There is no way to make an attribute / type in schema conditional -- this contradicts core terraform principles that resource schema is static and only attribute values can change.

@tico88612 But I really don't understand why those computed attributes are causing issues and why you need to ignore them? Could you share more details on your use case? perhaps attach full plan / apply log before / after?

[ylbeethoven]

Hi @bpg

Having attributes "known after apply" is completely normal for computed attributes, and shouldn't cause any issues.

I think this is true for VMs. For templates, they do not get IP addresses assigned hence terraform plan always returns diff in the output.

  ~ resource "proxmox_virtual_environment_vm" "ubuntu_template" {
        id                      = "9100"
      ~ ipv4_addresses          = [] -> (known after apply)
      ~ ipv6_addresses          = [] -> (known after apply)
        name                    = "temp-ubuntu-25-04"
      ~ network_interface_names = [] -> (known after apply)
        tags                    = [
            "terraform",
            "ubuntu",
        ]
        # (27 unchanged attributes hidden)

        # (9 unchanged blocks hidden)
    }

Maybe there are some configurations that I missed. Could you please advise how we can avoid this diff? Thank you

[bpg]

Template and VM are the same resource using the same schema, so we can't conditionally treat or ignore attributes in the schema. Perhaps adding a separate resource for the template is something I should consider 🤔

But regardless, I'm struggling to understand why you have the current behavior. Can you show your full apply output? Have you changed the network config in the template between terraform runs?

Changes only in computed attributes aren't enough to trigger, e.g. a resource replacement, so I don't see why you need to add them to ignore_changes. Does your workflow rely on the terraform plan output somehow?

[M-Paladin]

This "problem" exists since a while. I was in 0.50 that it was already there.
There's no harm having this result, it doesn't disturb anything.
The only "problem" is that this is displayed when you use tofu plan or tofu apply, even though there's not any change done to the templates and it kind of "pollutes" what you see because basically those changes are not existing per se.
When you only have 1 or 2 templates, that's manageable. But if you have let's say 10, then your screen is full of useless operations that don't really exist.

8391c43f03f6:/home/jenkins# tofu plan
module.cloud-init["grocy"].proxmox_virtual_environment_file.this: Refreshing state... [id=nfs:snippets/grocy.maison.lvsb.fr_CI_user-data.yaml]
module.cloud_images["debian-lxc-container-image"].proxmox_virtual_environment_download_file.this: Refreshing state... [id=nfs:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst]
module.cloud_images["debian-vm-cloud-image-12-1740"].proxmox_virtual_environment_download_file.this: Refreshing state... [id=nfs:iso/debian-12-genericcloud-amd64-20240507-1740.img]
module.cloud-init["jenkins-2"].proxmox_virtual_environment_file.this: Refreshing state... [id=nfs:snippets/jenkins-2.maison.lvsb.fr_CI_user-data.yaml]
module.cloud-init["dns-ext"].proxmox_virtual_environment_file.this: Refreshing state... [id=nfs:snippets/dns-ext.maison.lvsb.fr_CI_user-data.yaml]
module.cloud_images["debian-vm-cloud-image-13-2257"].proxmox_virtual_environment_download_file.this: Refreshing state... [id=nfs:iso/debian-13-genericcloud-amd64-20251006-2257.img]
module.cloud-init["dolibarr"].proxmox_virtual_environment_file.this: Refreshing state... [id=nfs:snippets/dolibarr.maison.lvsb.fr_CI_user-data.yaml]
module.cloud-init["jenkins-1"].proxmox_virtual_environment_file.this: Refreshing state... [id=nfs:snippets/jenkins-1.maison.lvsb.fr_CI_user-data.yaml]
module.lxc_containers["nfs-server-2"].terraform_data.version_date_replacement: Refreshing state... [id=c68a67cd-017c-0943-4790-9ef342aebb09]
module.virtual_machine_templates["vm-template-debian-B"].proxmox_virtual_environment_vm.this: Refreshing state... [id=9999]
module.lxc_containers["nfs-server-1"].terraform_data.version_date_replacement: Refreshing state... [id=f32a754b-090b-495a-c396-077596d8d66a]
module.virtual_machine_templates["vm-template-debian-A"].proxmox_virtual_environment_vm.this: Refreshing state... [id=9998]
module.lxc_containers["nfs-server-1"].proxmox_virtual_environment_container.this: Refreshing state... [id=115]
module.lxc_containers["nfs-server-2"].proxmox_virtual_environment_container.this: Refreshing state... [id=116]
module.virtual_machines["jenkins-1"].proxmox_virtual_environment_vm.this: Refreshing state... [id=103]
module.virtual_machines["dns-ext"].proxmox_virtual_environment_vm.this: Refreshing state... [id=113]
module.virtual_machines["dolibarr"].proxmox_virtual_environment_vm.this: Refreshing state... [id=117]
module.virtual_machines["grocy"].proxmox_virtual_environment_vm.this: Refreshing state... [id=100]
module.virtual_machines["jenkins-2"].proxmox_virtual_environment_vm.this: Refreshing state... [id=109]

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

OpenTofu will perform the following actions:

  # module.virtual_machine_templates["vm-template-debian-A"].proxmox_virtual_environment_vm.this will be updated in-place
  ~ resource "proxmox_virtual_environment_vm" "this" {
        id                      = "9998"
      ~ ipv4_addresses          = [] -> (known after apply)
      ~ ipv6_addresses          = [] -> (known after apply)
        name                    = "vm-template-debian-A"
      ~ network_interface_names = [] -> (known after apply)
        tags                    = [
            "13-2257",
            "debian",
            "production",
            "template",
            "vm",
        ]
        # (24 unchanged attributes hidden)

        # (6 unchanged blocks hidden)
    }

  # module.virtual_machine_templates["vm-template-debian-B"].proxmox_virtual_environment_vm.this will be updated in-place
  ~ resource "proxmox_virtual_environment_vm" "this" {
        id                      = "9999"
      ~ ipv4_addresses          = [] -> (known after apply)
      ~ ipv6_addresses          = [] -> (known after apply)
        name                    = "vm-template-debian-B"
      ~ network_interface_names = [] -> (known after apply)
        tags                    = [
            "12-1740",
            "debian",
            "production",
            "template",
            "vm",
        ]
        # (24 unchanged attributes hidden)

        # (6 unchanged blocks hidden)
    }

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

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so OpenTofu can't guarantee to take exactly these actions if you run "tofu apply" now.