[Bug]: importing primary IPs generally buggy

[pjagiello]

What happened?

Since the new flexible netowrking was introduced, I wanted to import primary IPs that already existed for my server, and also reflect that change for "hcloud_server" that already had these IPs assigned. Couple of unexpected things happened:

• on one of the applies, the ipv6 resource returned an error "invalid IP address" (the apply only changed the name, auto-delete and deletion protection parameters for this IP.). Given the fact that this was simply imported and I never had to actually provide this IP, this is a bit bizarre
• subsequent apply completed succesfully for the primary IPs, but hcloud_server reported "Error: All Floating IPs of type IPv4 have to be unassigned from Server (service_error)". The server does in fact have a floating IP assigned, but considering that I'm just adding a "public_net" block to the server, containing primary IPs that it already has assigned, I didn't expect the apply to actually do anything - the server already has these primary IPs in place. (Furthermore, this apply left the server turned off, which was also undesirable).

What did you expect to happen?

I expected the apply after the import to succeed, and effectively only change a bunch of parameters to the primary IPs, and do nothing for the hcloud_server.

Please provide a minimal working example

I think what would recreate my situation would be first to create this:

resource "hcloud_floating_ip" "main" {
  home_location = "fsn1"
  type = "ipv4"
}

resource "hcloud_floating_ip_assignment" "main_to_ip" {
  floating_ip_id = hcloud_floating_ip.main.id
  server_id      = hcloud_server.main.id
}

resource "hcloud_server" "main" {
  name        = "test"
  image       = "ubuntu-20.04"
  server_type = "cx11"
  location    = "fsn1"
}

Then once that is applied and succesfully created, adding this:

resource "hcloud_primary_ip" "main" {
  for_each = toset(["ipv4", "ipv6"])
  
  name          = "main_primary_${each.key}"
  datacenter    = "fsn1-dc14"
  type          = each.key
  assignee_type = "server"
  
  delete_protection = true
  auto_delete       = false
}

and this block to hcloud_server:

public_net {
    ipv4 = hcloud_primary_ip.main["ipv4"].id
    ipv6 = hcloud_primary_ip.main["ipv6"].id
  }

The import:

terraform import 'hcloud_primary_ip.main["ipv4"]' [ID]
terraform import 'hcloud_primary_ip.main["ipv6"]' [ID]

And then terraform apply causes things I'm describing (so first apply returns invalid IP, second apply complains about the floating IP and turns off the server, turning server back on manually and then doing apply works fine... except setting auto_delete doesn't work but that seems to be issue #565 and I'm assuming the fix wasn't released yet.

[pjagiello]

And one minor thing I forgot - documentation claims that "assignee_type" for hcloud_primary_ip was optional, but in practice I got "Missing required argument" error so I had to add it (hence it's in the example).

[b8dmin]

Also i wanted to add one more problem to this, in my opinion related to the public_ip case. Replay like this:

1. we have an already created server
2. define hcloud_primary_ip and hcloud_server (with public_net block)
3. import hcloud_primary_ip (works correctly)
4. import hcloud_server (successfully)
5. terraform plan....oops

  # module.vm.hcloud_server.servers["centos-xxxxx"] will be updated in-place
  ~ resource "hcloud_server" "servers" {
      + allow_deprecated_images    = false
        id                         = "123456"
      + ignore_remote_firewall_ids = false
      + keep_disk                  = false
      ~ labels                     = {
          + "source" = "terraform"
        }
        name                       = "centos-xxxxx"
        # (13 unchanged attributes hidden)

      + public_net {
          + ipv4         = 123456
          + ipv4_enabled = true
          + ipv6         = 654321
          + ipv6_enabled = true
        }

        # (1 unchanged block hidden)
    }

6. go to terraform.state and find our "public_net" section...cry

"public_net" : []

7. to correctly connect the server and primary_ip in the terraform state, you need to do "apply" , which will restart the server and reassign primary_ip. What can be critical for production servers

---

More recently there was a need to import 200+ servers. And this was one of the most unpleasant nuances.
In the end I bypassed it by applying a "dirty hack" - editing the state...pcre, scripting... But that's another story))

[daxroc]

There's a severe bug also when importing primary IP and then assigning it to an instance like

public_net {
    ipv4_enabled = true
    ipv4 = hcloud_primary_ip.gateway-v4.id
    ipv6_enabled = true
    ipv6 = hcloud_primary_ip.gateway-v6.id
  }

This resulted in the ipv4 primary IP being deleted and the terraform failing with the following.

Error: Primary IP with ID XXXXXXXX not found (not_found)
│
│   with hcloud_server.gateway,
│   on gateway.tf line 31, in resource "hcloud_server" "gateway":
│   31: resource "hcloud_server" "gateway" {

Where the plan only showed an update, not a destructive operation

+ public_net {
          + ipv4         = XXXXXXX
          + ipv4_enabled = true
          + ipv6         = XXXXXXX
          + ipv6_enabled = true
        }

PLEASE add a warning to the docs to enable the delete protection when importing so that others don't have a bad day.

[apricote]

Hey @daxroc, sorry to hear that you encountered a critical bug, could you post more detailed reproduction steps & your terraform code to help us fix the bug?

[github-actions]

This issue has been marked as stale because it has not had recent activity. The bot will close the issue if no further action occurs.

[jooola]

Sadly, like multiple other open issues, we will only be able to solve this by/after migrating to the plugin framework.

See #752 for more information about the migration.