Terraform wants to change mac address on reapply

[cospeedster]

Problem

When I plan the second run of terraform, it want to change the network blocks:

...

      + network {
          + bridge    = "vmbr0"
          + firewall  = false
          + id        = 0
          + link_down = false
          + model     = "virtio"
          + queues    = -1
          + rate      = -1
          + tag       = 2101
        }
      - network {
          - bridge    = "vmbr0" -> null
          - firewall  = false -> null
          - id        = 0 -> null
          - link_down = false -> null
          - macaddr   = "42:CE:92:97:95:4B" -> null
          - model     = "virtio" -> null
          - queues    = -1 -> null
          - rate      = -1 -> null
          - tag       = 2101 -> null
        }
      + network {
          + macaddr = "42:CE:92:97:95:4B"
        }
    }

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

Maybe this Issue has same cause for Issue #47. @ggongaware Mentioned this here #47 (comment).

Work around

For a work around I added this to my resource:

  # For some reason terraform has changes on reapply
  lifecycle {
    ignore_changes = [
      network,
    ]
  }

I don't know how I can just ignore changes on mac addresses.

Any Ideas there so far?

[cwiggs]

I had this same issue and adding your workaround does "solve" the problem for now, but isn't ideal.

An interesting thing about this bug is that when I tried to terraform apply without the lifecycle workaround in place terraform fails to apply, with this error: Error: 400 Parameter verification failed.

Sounds like it's getting a 400 back from the proxmox API.

[cospeedster]

@cwiggs I totaly agree, that this isn't the best way. That's why I opened this issue here.

[cwiggs]

@cospeedster I didn't mean to come off negative towards your workaround, sorry if I did. Thanks for the workaround and this issue!

I enabled terraform debugging and ran terraform with the lifecycle workaround commented out. the debug log is around 2k lines so I don't want to include the whole thing, but here is the response from the proxmox api with the 400 response:

2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: 2020/01/21 10:05:01 <<<<<<<<<< RESULT:
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: HTTP/1.1 400 Parameter verification failed.
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Connection: close
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Content-Length: 97
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Cache-Control: max-age=0
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Content-Type: application/json;charset=UTF-8
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Date: Tue, 21 Jan 2020 17:05:01 GMT
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Expires: Tue, 21 Jan 2020 17:05:01 GMT
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Pragma: no-cache
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: Server: pve-api-daemon/3.0
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox:
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: {"data":null,"errors":{"net0":"invalid format - missing key in comma-separated list property\n"}}
2020-01-21T10:05:01.976-0700 [DEBUG] plugin.terraform-provider-proxmox: 2020/01/21 10:05:01 400 Parameter verification failed.
2020/01/21 10:05:01 [DEBUG] module.k3s-cluster.proxmox_vm_qemu.this: apply errored, but we're indicating that via the Error pointer rather than returning it: 400 Parameter verification failed.

If anyone needs more of the debug log, let me know.

[cospeedster]

@cwiggs No, you missunderstood me. I did not even get it in a negative way. :)

[f0rkz]

Anyone able to tackle this at all?

[Cadair]

As mentioned in #88 this also applies to the cipassword variable as well, the workaround helps with that too. 😄

[ardentsword]

As mentioned in #88 this also applies to the cipassword variable as well, the workaround helps with that too.

The cipassword is a way more troublesome problem. If you add it to the ignore_changes it is still send whenever you apply. This means that the ci_image still thinks there are changes and will mess up the ssh fingerprint on the next (re)boot. The solution we currently use is to make the cipassword empty, this will prevent a changed ci_image trigger.

[Cadair]

I haven't noticed that behaviour, thanks for the heads up.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Please update the provider to the latest version and, in the issue persist, provide full configuration and debug logs

[github-actions]

This issue was closed because it has been inactive for 5 days since being marked as stale.