Open n0ct1s-k8sh opened 3 weeks ago
Hi @n0ct1s-k8sh
From your output:
~ resource "proxmox_virtual_environment_vm" "vm_template_debian_12_20240717" {
id = "100"
~ ipv4_addresses = [] -> (known after apply)
~ ipv6_addresses = [] -> (known after apply)
name = "template-debian-12-20240717"
~ network_interface_names = [] -> (known after apply)
tags = [
"debian12",
"gnu+linux",
]
# (25 unchanged attributes hidden)
~ disk {
~ file_format = "raw" -> "qcow2"
# (12 unchanged attributes hidden)
}
# (9 unchanged blocks hidden)
}
I see only disk.file_format
is mishandled and causing the resource update.
ipv4_addresses
, ipv6_addresses
, network_interface_names
are computed attributes, their values are retrieved from the VM, hence (known after apply)
status. They are not to be updated in-place (i.e. in the VM), but marked with ~
as potentially to be updated in the TF state with the new values after apply.
I was also getting architecture creating a diff to be updated in-place but then after using an image with qemu agent pre-installed the diff went away.
Edit: Actually getting a diff now after adding a few more VMs on the architecture. Not sure why I thought this was resolved before since I remember specifically testing if I got a diff after another apply.
~ cpu {
+ architecture = "x86_64"
# (9 unchanged attributes hidden)
}
So this definitely seems like a bug.
@bpg While I can appreciate your comment about the values being "potentially" updated by the VM, this does have a bit of a "false positive" bug kinda feel to it. After all, terraform plan
is saying it wants to make 1 change. In a professional environment, that's not going to cut it and once the constant explanations wear thin, the condition will just be known and referred to as "that buggy provider's problem". Not saying that's correct... just saying that's the perception when it comes to false positives like this.
After confirming each of these are just empty lists in the state, I guess I'm wondering why they'd need to exist in the state to begin with? Granted, my question relates specifically to a template which has not been created with a initialization
block like above.
I also always seem to get the architecture to be updated on new machines even when the cpu architecture is specifically set in the config
# (30 unchanged attributes hidden)
~ cpu {
+ architecture = "x86_64"
# (9 unchanged attributes hidden)
}
# (7 unchanged blocks hidden)
@windowsrefund
After all, terraform plan is saying it wants to make 1 change
Yes, this is the actual problem I mentioned regarding the file_format
attribute.
After confirming each of these are just empty lists in the state, I guess I'm wondering why they'd need to exist in the state to begin with?
The fact that other attributes like ipv4_addresses
are marked as "changed" (~
) with the value (known after apply)
is expected because those attributes are computed, and their values are not known during the plan. They are in the state because we want to retrieve them after the VM resource creation. But in your case, this is a template, and the VM is not started, so there are no IPs.
There is nothing wrong with the computed attributes; we use quite a lot of them. The problem lies with the "regular" attributes that change value when the provider reads them back from PVE after resource creation (mostly) or update (rarely). These cases are bugs, for sure, and they are present across many resources implemented using the old and deprecated Terraform Plugin SDK. These issues are not always straightforward to fix, as the old SDK does not provide the necessary methods to handle default values for attributes, which is a root cause of these discrepancies.
The long-term plan is to fix all such bugs in the VM resource, as outlined in #1231.
In a professional environment, that's not going to cut it and once the constant explanations wear thin, the condition will just be known and referred to as "that buggy provider's problem".
Agreed, that's not ideal. However, this is a hobby project, and there are only so many hours left in a day after a day job and other commitments. I hope people understand.
@GeorgeGedox this should be fixed in #1524
When you create a virtual machine template (although I don't know if it happens in standalone VMs), the following properties are marked to be updated in-place always, even after every apply:
This is my shell log when I apply and plan for the first time:
Steps to reproduce the behavior:
proxmox_virtual_environment_download_file
resource to download a qcow2 disk image (file extension renamed to.img
as the documentation says in thefile_name
option).proxmox_virtual_environment_vm
resource to create a VM template with the previously downloaded file as the disk.tofu apply
to create all resources for the first time.tofu plan
and apply those new changes.tofu plan
and the same changes are required to apply again and again.Please also provide a minimal Terraform configuration that reproduces the issue.
Image download definition:
VM Template definition:
Expected behavior It is expected to not have any pending changes in the VM resource.
Screenshots
![image](https://github.com/user-attachments/assets/7796567b-d042-4d62-9b70-fb99b2750d69)
TF_LOG=DEBUG terraform apply
): Attached in the post. apply.log