muhlba91/pulumi-proxmoxve

Resizing disk on a clone endless loop

pcuci opened this issue · 2 comments

pcuci commented

On subsequent pulumi up's, details shows:

  [provider=urn:pulumi:omega::cloud::pulumi:providers:proxmoxve::proxmoxve::7624107a-857f-46a6-a906-452dd1fea95d]
    ~ disk: {
        ~ size: 32 => 100
      }

What seems to happen is the CT gets created based on the clone (32GiB disk), but I want the drive to be bigger; and that only gets picked up after* the clone happens, on subsequent pulumi ups

I don't see a Proxmox UI option to "clone and resize" in one go, so I'm wondering if I could configure the provider differently(?)

The funny part is that it recreates the container when it replaces the disk, and the recreated CT has 32GiB disk size(!); and so on...

The template is itself a stopped container: https://gitlab.com/home.cloud/infra/template/-/blob/main/index.ts?ref_type=heads#L42-45 in an upstream stack that I import to reuse here: https://gitlab.com/home.cloud/infra/cloud/-/blob/main/index.ts?ref_type=heads#L93-110

One option would be to create differently sized templates, but that would defeat the original purpose 😄

Are changes to disk.size forced by the upstream tf-provider?

Appreciate any hints, thanks!

muhlba91 commented

i do believe this is a limitation of Proxmox itself.

looking at https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/lxc/{vmid}/clone you can see the parameters Proxmox accepts for a container clone, which doesn't contain any disk related parameters (except for the datastore).
hence, Proxmox will take the existing container and clone it as is. for containers, there's one note in the full property which i can't interpret so far saying that by default a linked clone is created. maybe that will solve the problem of it going into a loop?

apart from that, you can see the same in the upstream code:
https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmoxtf/resource/container.go#L796 is the code that creates the request parameters, and https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmox/nodes/containers/containers.go#L20 performs the request itself. since you set the clone parameter you are calling this method chain in https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmoxtf/resource/container.go#L790.

  • ❤️1
pcuci commented

Oh well, it was worth a try 😸

I went for re-cloning the template and resizing its disk against the destination datastoreId, then I clone this clone to get the container.

https://gitlab.com/home.cloud/infra/cloud/-/blob/main/src/ct/index.ts?ref_type=heads#L95-157

create: pulumi.interpolate`
  # Check for non-existence of preclone
  while pct list | grep -q "^${tempCloneId} "; do
    echo "Temporary clone ID ${tempCloneId} is in use. Waiting..."
    sleep 5
  done

  # Perform clone and resize
  pct clone ${template.id} ${tempCloneId} --full --storage ${datastoreId} &&
  pct resize ${tempCloneId} rootfs ${size}G
`

As I'm creating multiple containers and Proxmox locks the template while it's cloning it, we need to serialize everything. It looks pretty bad, but seems to work. A better design would be to create a higher level ProxmoxVE Dynamic Provider (haha) to hide away all these remote.Commands and bypass this limitation:

image

Thanks for helping me understand what's going on under the hood!