Provider produced inconsistent final plan when referencing another container's volume

[Robzz]

Hi there, thanks for your work on this provider!

Describe the bug
When attempting to apply the snippet below, OpenTofu fails with Error: Provider produced inconsistent final plan on the first tofu apply attempt after creating the first container. Second attempt is able to create the second container properly.

To Reproduce
A short explanation of the snippet is probably in order as this might look a bit weird: it creates 2 containers, the first one is not intended to be booted, and exists solely to own a data volume in addition to its boot disk (though again, we won't boot it). The second one is the actual workload, and it mounts the data volume owned by the first container. The reason for doing it this way is to prevent the application data volume being deleted when Tofu decides to recreate the second container for whatever reason, since technically it doesn't own that volume, the first container does.

resource "proxmox_virtual_environment_container" "data" {
  description = "Data container - Not a real workload"

  unprivileged = true
  node_name    = "proxmox"

  initialization {
    hostname = "issue-repro-data"
  }

  operating_system {
    template_file_id = "local:vztmpl/alpine-3.21-default_20241217_amd64.tar.xz"
    type             = "alpine"
  }

  disk {
    datastore_id = "local-lvm"
    size         = 1
  }

  mount_point {
    volume = "local-lvm"
    size   = "1G"
    # We don't actually care about the path since we won't boot this container, but it's mandatory
    path   = "/mnt/data"
  }

  protection = true
  start_on_boot = false
  started       = false
}

resource "proxmox_virtual_environment_container" "workload" {
  description = "Workload container - Mounts volume from issue-repro-data container"

  unprivileged = true
  node_name    = "proxmox"

  initialization {
    hostname = "issue-repro-workload"
  }

  operating_system {
    template_file_id = "local:vztmpl/alpine-3.21-default_20241217_amd64.tar.xz"
    type             = "alpine"
  }

  disk {
    datastore_id = "local-lvm"
    size         = 1
  }

  mount_point {
    volume = proxmox_virtual_environment_container.data.mount_point[0].volume
    path   = "/mnt/mysql-data"
  }
}

Which produces the following output:

OpenTofu used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # proxmox_virtual_environment_container.data will be created
  + resource "proxmox_virtual_environment_container" "data" {
      + description    = <<-EOT
            Data container - Not a real workload
        EOT
      + id             = (known after apply)
      + node_name      = "proxmox"
      + protection     = false
      + start_on_boot  = false
      + started        = false
      + template       = false
      + timeout_clone  = 1800
      + timeout_create = 1800
      + timeout_delete = 60
      + timeout_start  = 300
      + timeout_update = 1800
      + unprivileged   = true
      + vm_id          = (known after apply)

      + disk {
          + datastore_id = "local-lvm"
          + size         = 1
        }

      + initialization {
          + hostname = "issue-repro-data"
        }

      + mount_point {
          + acl       = false
          + backup    = false
          + path      = "/mnt/data"
          + quota     = false
          + read_only = false
          + replicate = true
          + shared    = false
          + size      = "1G"
          + volume    = "local-lvm"
        }

      + operating_system {
          + template_file_id = "local:vztmpl/alpine-3.21-default_20241217_amd64.tar.xz"
          + type             = "alpine"
        }
    }

  # proxmox_virtual_environment_container.workload will be created
  + resource "proxmox_virtual_environment_container" "workload" {
      + description    = <<-EOT
            Workload container - Mounts volume from issue-repro-data container
        EOT
      + id             = (known after apply)
      + node_name      = "proxmox"
      + protection     = false
      + start_on_boot  = true
      + started        = true
      + template       = false
      + timeout_clone  = 1800
      + timeout_create = 1800
      + timeout_delete = 60
      + timeout_start  = 300
      + timeout_update = 1800
      + unprivileged   = true
      + vm_id          = (known after apply)

      + disk {
          + datastore_id = "local-lvm"
          + size         = 1
        }

      + initialization {
          + hostname = "issue-repro-workload"
        }

      + mount_point {
          + acl       = false
          + backup    = false
          + path      = "/mnt/mysql-data"
          + quota     = false
          + read_only = false
          + replicate = true
          + shared    = false
          + volume    = "local-lvm"
        }

      + operating_system {
          + template_file_id = "local:vztmpl/alpine-3.21-default_20241217_amd64.tar.xz"
          + type             = "alpine"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.
proxmox_virtual_environment_container.data: Creating...
proxmox_virtual_environment_container.data: Creation complete after 3s [id=50002]

Error: Provider produced inconsistent final plan

When expanding the plan for proxmox_virtual_environment_container.workload to
include new values learned so far during apply, provider
"registry.opentofu.org/bpg/proxmox" produced an invalid new value for
.mount_point[0].volume: was cty.StringVal("local-lvm"), but now
cty.StringVal("local-lvm:vm-50002-disk-1").

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Expected behavior
tofu apply should work to completion without errors on the first attempt

Additional context

• Single or clustered Proxmox: single
• Proxmox version: 8.3.4
• Provider version (ideally it should be the latest version): 0.73.0
• Terraform/OpenTofu version: 1.9.0
• OS (where you run Terraform/OpenTofu from): Linux

[bpg]

Hey @Robzz 👋🏼

The issue with the mount_point.volume attribute is that it gets updated during apply when a new volume is provisioned, like in your case with the "data" container. During the plan phase, the "workload" container still sees the old value from "data" ("local-lvm"). However, during apply, the value is updated to "local-lvm:vm-50002-disk-1" and applied to the container. Then, when Terraform reads the state back after apply, it detects an inconsistency between the config and the actual state, resulting in an error.

As a workaround, you can explicitly specify the volume ID in the "workload" container instead of referencing it from "data." This requires constructing the volume ID manually, but it’s manageable if you use fixed VM IDs.

A more permanent fix would be to avoid updating the mount_point.volume value directly and instead introduce a new attribute, like volume_id. I'll need to think this through tho, considering all mount_point use cases and ensuring backward compatibility with current deployments.