terraform-provider-proxmox icon indicating copy to clipboard operation
terraform-provider-proxmox copied to clipboard

start_on_boot not applied on CT

Open JD-ISWT opened this issue 1 year ago • 5 comments

Describe the bug

Parameter start_on_boot is not working as expected on CT

To Reproduce

  1. Create a resource proxmox_virtual_environment_container
  2. Set parameter start_on_boot to true, or let the default value
  3. Run terraform plan/ terraform apply
  4. The resource is created in Proxmox, available in the state, with the correct settings
  5. The flag Start at bootis set to false in Options tab in Proxmox GUI and in LXC config files

Please also provide a minimal Terraform configuration that reproduces the issue.


resource "proxmox_virtual_environment_container" "meets" {
  description = "Managed by Terraform"

  node_name = "xxxxx"

  vm_id        = 101
  unprivileged = false

  tags = ["tag1", "tag2"]

  start_on_boot = true

  clone {
    datastore_id = "data"
    node_name = "xxxxx"
    vm_id = "100"
  }

  initialization {
    hostname = "xxxxx"

    ip_config {
      ipv4 {
        address = "xxxxx"
        gateway = "xxxxx"
      }
    }
  }

  network_interface {
    name   = "eth0"
    bridge = "vmbr2"
  }

  console {
    enabled   = true
    tty_count = 2
    type      = "tty"
  }

  disk {
    datastore_id = "data"
    size         = 25
  }

  memory {
    dedicated = 8192
    swap      = 2048
  }

  cpu {
    architecture = "amd64"
    cores        = 4
    units        = 1024
  }

  lifecycle {
    ignore_changes = [description]
  }
}

State is correct:

# proxmox_virtual_environment_container.meets:
resource "proxmox_virtual_environment_container" "meets" {
    description   = <<-EOT
        Managed by Terraform
    EOT
    id            = "101"
    node_name     = "xxxxx"
    start_on_boot = true
    started       = true
    tags          = [
        "tag1",
        "tag2",
    ]
    template      = false
    unprivileged  = false
    vm_id         = 101

    clone {
        datastore_id = "data"
        node_name    = "xxxxx"
        vm_id        = 100
    }
[...]

Expected behavior Flag start_on_boot set to true on Proxmox

Screenshots

image

root@ns31482010:~# cat /etc/pve/nodes/xxxxx/lxc/101.conf 
#Managed by Terraform
arch: amd64
cmode: tty
console: 1
cores: 4
cpuunits: 1024
features: nesting=1
hostname: xxxxx
memory: 8192
net0: name=eth0,bridge=vmbr2,firewall=0,gw=xxxxx,hwaddr=xxxxx,ip=xxxxx,type=veth
onboot: 0
ostype: debian
rootfs: data:vm-101-disk-0,size=25G
swap: 2048
tags: tag1;tag2
tty: 2
unprivileged: 1

Additional context Add any other context about the problem here.

  • Single Proxmox: 8.0.4
  • Provider version: 0.40.0
  • Terraform version: 1.6.5
  • OS (where you run Terraform from): Debian
  • Debug logs (TF_LOG=DEBUG terraform apply):

JD-ISWT avatar Dec 12 '23 09:12 JD-ISWT

Seems that the fix works only for newly created resources, the update is not working properly (ie no changes when applied)

In both sides

All my CTs have start_at_boot flag to off (because created with previous version). I changed the setting in TF to off, applied, then switch again to on to force applied and nothing change in Proxmox.

When using -recreate the new resource is created with start_at_boot flag to true. But, when set it to false, the change is not applied in Proxmox

I tested with 0.43

JD-ISWT avatar Jan 09 '24 09:01 JD-ISWT

Thanks for testing @JD-ISWT, I'll reopen the ticket.

bpg avatar Jan 10 '24 03:01 bpg

Hi, I don't know if that's related but it seems features are not applied either. For a cloned container (the template has keyctl and nesting to 1) :

  # proxmox_virtual_environment_container.cts[0] will be updated in-place
  ~ resource "proxmox_virtual_environment_container" "cts" {
        # (12 unchanged attributes hidden)

      ~ features {
          ~ keyctl  = true -> false
          ~ nesting = true -> false
            # (2 unchanged attributes hidden)
        }

        # (6 unchanged blocks hidden)
    }

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

image

Please tell me if I need to open another issue

zeylos avatar May 19 '24 20:05 zeylos

@zeylos thanks for adding these details.

No need for a new ticket, the bug it in the same area, all related to clone and handling default values.

I did not look deeper into that, but have a feeling that it might not be easy to fix in the current implementation. #1231 is to solve a set of similar issues for VM, and we'd need pretty much the same rewrite for LXC.

bpg avatar May 23 '24 02:05 bpg