hetznercloud / terraform-provider-hcloud

Terraform Hetzner Cloud provider
https://registry.terraform.io/providers/hetznercloud/hcloud/latest
Mozilla Public License 2.0
491 stars 71 forks source link

[Bug]: Since upgrading to terraform 1.4.x, the provider keeps trying to remove and re-assign private networks #650

Open ttaghavi opened 1 year ago

ttaghavi commented 1 year ago

What happened?

After upgrading from terraform 1.3.9 to 1.4.x, I see following behavior.

NOTE: Am using the latest version for terraform-provider-hcloud.

provider "registry.terraform.io/hetznercloud/hcloud" {
  version     = "1.37.0"
  constraints = "~> 1.37.0"

Network resources

resource "hcloud_network" "cluster_network_eu_central" {
  name     = "cluster-network-eu-central"
  ip_range = "10.0.0.0/16"

  delete_protection = false
}                                                                                                                      

resource "hcloud_network_subnet" "cluster_subnet_eu_central" {
  type         = "cloud"
  network_id   = hcloud_network.cluster_network_eu_central.id
  network_zone = "eu-central"
  ip_range     = "10.0.1.0/24"
}

The hcloud_server resource then uses this network via:

  network {
    network_id = hcloud_network.cluster_network_eu_central.id
  }

On a first run, everything is created correctly.

On subsequent runs (without changing any terraform files), I get:

 ~ resource "hcloud_server" "node" {
        id                         = "<server_id>"
        name                       = "server-fsn1-cpx11-1"
        # (18 unchanged attributes hidden)

      - network {
          - alias_ips   = [] -> null
          - ip          = "10.0.1.6" -> null
          - mac_address = "<mac_address> -> null
          - network_id  = <network_id> -> null
        }
      + network {
          + alias_ips   = (known after apply)
          + ip          = (known after apply)
          + mac_address = (known after apply)
          + network_id  = <network_id>
        }

        # (1 unchanged block hidden)
    }

Applying this plan detaches the private ip from the servers and re-attaches them. Further runs behave exactly the same.

Reverting back to 1.3.9 correctly shows:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

What did you expect to happen?

Same output as 1.3.9.

Please provide a minimal working example

See What ahappened? field.

apricote commented 1 year ago

I can confirm that this also happens for me.

Unfortunately we have some holidays coming up in Germany, so I don't think I will be able to take a deeper look at this until next week. Please continue to use Terraform v1.3 for now.

apricote commented 1 year ago

I was able to supress the diff by adding alias_ips = [] to the network block. I think this is a new bug in Terraform. Will continue to investigate in the coming weeks.


resource "hcloud_server" "node" {
  name        = "gh-650"
  location    = "hel1"
  server_type = "cx11"
  image       = "ubuntu-22.04"

  network {
    network_id = hcloud_network.cluster_network_eu_central.id
+   alias_ips = []
  }
}
ttaghavi commented 1 year ago

Thanks for the feedback @apricote

I can confirm that setting alias_ips = [] suppresses the diff.

apricote commented 1 year ago

I think this regression was willfully added to Terraform v1.4 in hashicorp/terraform#32536 :

While it may be safer to leave the questionable set block behavior as-is to avoid possible regressions with legacy providers, the framework has added full support for nested blocks, which means that new providers now have access to the complete values and are no longer limited by the behaviors of the legacy SDK. A number of tests cases for nested set blocks were added here, which do fail without the accompanying changes.

This is unfortunately a large refactoring that is expected of us here. As far as I can tell this should affectshcloud_server.network.alias_ips and hcloud_firewall.rule.{source,destination}_ips, but I can only reproduce it for the server resource and dont understand why. I will have another look at this tomorrow.

spoletum commented 1 year ago

The same applies to public networks, issue and resolution.

furstenbergs commented 1 year ago

I'm currently using version 1.41.0 of the hcloud provider and Terraform 1.5.2.

I'm assigning an alias IP to my resource, for example;

  network {
    network_id = hcloud_network.private.id
    ip         = "10.100.0.2"
    alias_ips  = [
      "10.100.127.10"
    ]
  }

The alias IP is assigned successfully, but on subsequent run, it's removing the alias IP without any code change.

# hcloud_server_network.server will be updated in-place
  ~ resource "hcloud_server_network" "server-network-az1" {
      ~ alias_ips   = [
          - "10.100.127.10",
        ]
        id          = "34780594-3110924"
        # (4 unchanged attributes hidden)
    }

And on the next run it add the alias IP back again, etc. I've tried different versions of Terraform, including 1.3.8, 1,4,1 but the issue remains. Also tried with older versions of the hcloud provider with no luck.

apricote commented 1 year ago

@furstenbergs If this still happens in Terraform 1.3, please open a new issue as its unrelated to this issue. Could you also post a full terraform configuration for reproduction?

asteinba commented 12 months ago

Hey @apricote,

just ran into this and searched a while for the solution. The alias_ips= [] workaround works well. Is there a update about that issue? Anything we can do to support you with this issue :)?

apricote commented 12 months ago

Hey @asteinba,

sorry for not updating this issue. As far as I could find out, updating the the "new" Plugin Framework is the only way to get this fixed. We had our first refactoring session this week (#749), and we plan an making slow but steady progress on this. In any way, the hcloud_server resource is by far the most complicated resource we have, and we will probably tackle this one last.

github-actions[bot] commented 9 months ago

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.