ionos-cloud/terraform-provider-ionoscloud

bug: impossible to use some image captures & inconsistent behavior

hegerdes opened this issue · 8 comments

hegerdes commented

Description

There are two ways to set the OS image for a system. Either via the image_name attribute in ionoscloud_server or via an ID that is fetched from the image datasource attribute. They behave differently leading to bugs and no possibility to select certan images.

Consider this:
Two images ubuntu-20.04-amd64 and ubuntu-20.04-amd64-2023-10-01. Both in all regions, both with cloudInit, both HDD, same attributes.

When you use datasource the is no way to distinguish the two images, because name allows partial matches. Resulting in more than one match -> resulting in an error

data "ionoscloud_image" "boot" {
  name     = "ubuntu-20.04-amd64"
  type     = "HDD"
  location = "de/txl"
}

Error:

Error: more than one image found, enable debug to learn more. Criteria used name = ubuntu-20.04-amd64, type = HDD, location = de/txl, version = , cloudInit = , imageAlias =

  with data.ionoscloud_image.boot,
  on main.tf line 23, in data "ionoscloud_image" "boot":
  23: data "ionoscloud_image" "boot" {

Using image_alias is also no solution than there is no way AFAIK to set this field via the DCD or ionosctl

The alternative to use ionoscloud_server works but produces unexpected results:

resource "ionoscloud_server" "example" {
    name                  = "Server Example"
    datacenter_id         = ionoscloud_datacenter.example.id
    cores                 = 1
    ram                   = 1024
    availability_zone     = "ZONE_1"
    cpu_family            = "AMD_OPTERON"
    image_name            = "ubuntu-20.04-amd64"
...

This just creates a VM with the image ubuntu-20.04-amd64-2023-10-01 because it does partial matches and just uses the first one that is found.

So there is no way to use the image you want.

Expected behavior

Use the image specified and not a other one that has almost the same name.

Environment

Terraform version:

Terraform v1.6.1
on windows_amd64
+ provider registry.terraform.io/hashicorp/random v3.5.1
+ provider registry.terraform.io/ionos-cloud/ionoscloud v6.4.9

Provider version:

ionoscloud v6.4.9

OS:

Windows 11 & RedHat Enterprise

Configuration Files

How to Reproduce

Error and Debug Output

Additional Notes

Please consider a major image upload and usage system - the current state it unusable

Also, another bug is when you run terraform destroy but the image_name changed terraform fails with an immutable error. This should not happen in destroy, since the resource will be gone anyway.

References

cbeti-ionos commented

currently you can get the exact match behavior you are looking for in the data source by using the name and version field combination:

data "ionoscloud_image" "boot" {
  name     = "ubuntu"
  version  = "20.04-amd64"
  type       = "HDD"
  location = "de/txl"
}

the name field alone does not have this behavior, this will be fixed

hegerdes commented

Except for this part:

If both "name" and "version" are provided the plugin will concatenate the two strings in this format [name]-[version].

There is no reference of a version attribute. So docs can be improved.
It also only allows image names in this format. So semantic version schema naming is not supported. For now we needed a solution and just switched the image name to use latest as their postfix - making them unique.

Most important is to get the behavior of ionoscloud_server fixed when the name is directly applied.

cbeti-ionos commented

the exact match behavior for the image name in ionoscloud_image and ionoscloud_server will be fixed in the next release

  • 👍1
hegerdes commented

Great!

Also, another bug is when you run terraform destroy but the image_name changed terraform fails with an immutable error. This should not happen in destroy, since the resource will be gone anyway.

Will this also be fixes?

cbeti-ionos commented

Can you describe the scenario a little more? It shouldn't be possible to change the image_name since it's an immutable field.

hegerdes commented

Sure, it not a serious problem but can be annoying.

Consider this:

  • Have a stack configured with input vars supplied by a generated file or via command line.
  • Now you want to destroy the steck but only have the state file and IaC code - but not the original supplied vars. So the vars fall back to defaults.
  • Some vars might have changed, immutable or not - like the image. But fields beeing immutable should not matter if you want to destroy the stack.
  • The IONOS provider throws an error here - most other providers I used just ignore immutable errors when destroy is run.
cristiGuranIonos commented

Yes, this is an annoying behavior. The way terraform usually deals with immutable is to force re-creation of the resource.
We throw an error, but this makes it difficult to see if a destroy is triggered. One wokraround is to run terraform destroy -refresh=false

  • 👍1