lxc / terraform-provider-incus

Incus provider for Terraform/OpenTofu
https://linuxcontainers.org/incus
Mozilla Public License 2.0
35 stars 8 forks source link

`image` should not be required for `incus_instance` #42

Closed stgraber closed 1 week ago

stgraber commented 4 months ago

Instances can be created with an empty image, this is particularly useful for VMs.

sysadminsavage commented 1 month ago

Another issue i found is when I import my existing incus containers into Terraform it then requires the "image" argument to do anything.

$ terraform plan
 Error: Missing required argument
The argument "image" is required, but no definition was found.

And if i do define the image, the terraform incus provider wants to force a replacement of the container.. (even though i've defined the same image that was used to deploy the container manually). For example-

$ incus image launch images:debian/trixie pihole --network macvlan
$ terraform import incus_instance.pihole pihole
Import successful!
$ terraform plan
  # incus_instance.pihole must be replaced
-/+ resource "incus_instance" "pihole" {
      + image            = "images:debian/trixie" # forces replacement
      ~ ipv4_address     = "192.168.20.144" -> (known after apply)
      ~ ipv6_address     = "fe80::216:3eff:fe59:b91a" -> (known after apply
      ~ mac_address      = "00:16:3e:59:b9:1a" -> (known after apply)
        name             = "pihole"
      ~ profiles         = [
          ~ "default" -> "macvlan",
        ]
      ~ status           = "Running" -> (known after apply)
      + target           = (known after apply)
        # (7 unchanged attributes hidden)

      - device {
          - name       = "eth0" -> null
          - properties = {
              - "name"    = "eth0"
              - "network" = "macvlan"
            } -> null
          - type       = "nic" -> null
        }
    }
maveonair commented 1 month ago

Another issue i found is when I import my existing incus containers into Terraform it then requires the "image" argument to do anything.

$ terraform plan
 Error: Missing required argument
The argument "image" is required, but no definition was found.

And if i do define the image, the terraform incus provider wants to force a replacement of the container.. (even though i've defined the same image that was used to deploy the container manually). For example-

$ incus image launch images:debian/trixie pihole --network macvlan
$ terraform import incus_instance.pihole pihole
Import successful!
$ terraform plan
  # incus_instance.pihole must be replaced
-/+ resource "incus_instance" "pihole" {
      + image            = "images:debian/trixie" # forces replacement
      ~ ipv4_address     = "192.168.20.144" -> (known after apply)
      ~ ipv6_address     = "fe80::216:3eff:fe59:b91a" -> (known after apply
      ~ mac_address      = "00:16:3e:59:b9:1a" -> (known after apply)
        name             = "pihole"
      ~ profiles         = [
          ~ "default" -> "macvlan",
        ]
      ~ status           = "Running" -> (known after apply)
      + target           = (known after apply)
        # (7 unchanged attributes hidden)

      - device {
          - name       = "eth0" -> null
          - properties = {
              - "name"    = "eth0"
              - "network" = "macvlan"
            } -> null
          - type       = "nic" -> null
        }
    }

The correct import command would be:

$ terraform import incus_instance.pihole default/pihole,image=images:debian/trixie

The reason for this is that our entire import logic works in this way. That is, you would have to pass all the important fields to the import command. I know this is not the most convenient way, but this is how our current import logic works across all resources.

sysadminsavage commented 1 month ago

The correct import command would be:

$ terraform import incus_instance.pihole default/pihole,image=images:debian/trixie

The reason for this is that our entire import logic works in this way. That is, you would have to pass all the important fields to the import command. I know this is not the most convenient way, but this is how our current import logic works across all resources.

that's perfectly fine - thanks for the clarification. i missed that.

JulesdeCube commented 2 weeks ago

Hello, I'd like to work on this issue if it's possible

stgraber commented 2 weeks ago

Sure, I assigned it to you!