hashicorp / terraform-provider-google

Terraform Provider for Google Cloud Platform
https://registry.terraform.io/providers/hashicorp/google/latest/docs
Mozilla Public License 2.0
2.3k stars 1.73k forks source link

google_compute_network: auto_create_subnetworks = {true -> false} causes resource re-creation #10052

Open gmile opened 3 years ago

gmile commented 3 years ago

Community Note

Terraform Version

Terraform v1.0.5

More ``` on darwin_amd64 + provider registry.terraform.io/cloudflare/cloudflare v2.21.0 + provider registry.terraform.io/cyrilgdn/postgresql v1.13.0 + provider registry.terraform.io/hashicorp/google v3.71.0 + provider registry.terraform.io/hashicorp/helm v2.1.2 + provider registry.terraform.io/hashicorp/kubernetes v2.3.1 + provider registry.terraform.io/hashicorp/local v2.1.0 + provider registry.terraform.io/hashicorp/random v3.1.0 + provider registry.terraform.io/integrations/github v4.11.0 + provider registry.terraform.io/louy/uptimerobot v0.5.1 + provider registry.terraform.io/rjpearson94/twilio v0.11.0 + provider registry.terraform.io/trois-six/sendgrid v0.1.6 Your version of Terraform is out of date! The latest version is 1.0.6. You can update by downloading from https://www.terraform.io/downloads.html ```

Affected Resource(s)

Terraform Configuration Files

resource "google_compute_network" "my_network" {
  name = "my-network"
}

Debug Output

None.

Panic Output

None.

Expected Behavior

Changing from:

resource "google_compute_network" "my_network" {
  name = "my-network"
}

...to:

resource "google_compute_network" "my_network" {
  name = "my-network"
  auto_create_subnetworks = false
}

...does not trigger re-creation of network (as well as dependent resources), similarly to how Google Cloud console UI handles checking off the flag.

Actual Behavior

Changing from:

resource "google_compute_network" "my_network" {
  name = "my-network"
}

...to:

resource "google_compute_network" "my_network" {
  name = "my-network"
  auto_create_subnetworks = false
}

...triggers re-creation of network (as well as dependent resources).

Steps to Reproduce

  1. define a new network:

    resource "google_compute_network" "my_network" {
      name = "my-network"
    }
  2. run: terraform apply

  3. update network resource definition:

    resource "google_compute_network" "my_network" {
      name = "my-network"
      auto_create_subnetworks = false
    }
  4. Observe planned recreation of resource.

Important Factoids

None.

References

b/312911472

slevenick commented 3 years ago

Yeah, so if you notice the Default: true, on that schema entry it means that if you don't set auto_create_subnetworks in your config the provider will default this value to true. This means that your first step of defining the network is essentially saying:

resource "google_compute_network" "my_network" {
  name = "my-network"
  auto_create_subnetworks = true # implied from default
}

So when you update the config to set the value to false, Terraform detects a diff and correctly forces a recreation.

slevenick commented 3 years ago

And I believe this is correctly marked as ForceNew because it determines what action is taken at create time, so modifying it after create should have no impact.

gmile commented 3 years ago

Terraform detects a diff and correctly forces a recreation

Right, current behaviour is understandable.

I'm challenging whether this behaviour can be adjusted to match that of Google Cloud API. Google Cloud Console, for example, allows switching network's auto_create_subnetworks from true to false without forcing network re-creation. Question is, could google_compute_network resource possibly be made similarly "tolerant" to said change and update the resource in-place?

For completeness, the behaviour according to Google Cloud API:

Currently I work around this issue like this:

After this sequence, running terraform apply won't be noticing any changes.

slevenick commented 3 years ago

Does changing auto_create_subnetworks change the type of the network? As I understand it that field controls the type (legacy vs non-legacy) of the network being created. I don't believe this can be changed after the fact.

The REST API docs say:

"Must be set to create a VPC network. If not set, a legacy network is created. When set to true, the VPC network is created in auto mode. When set to false, the VPC network is created in custom mode."

Changing this field may be possible, but I don't believe it would change the underlying mode of the network

gmile commented 3 years ago

Changing this field may be possible, but I don't believe it would change the underlying mode of the network

I don't believe changing auto_create_subnetworks impacts the type (legacy vs non-legacy) of the network either.

As I understand it that field controls the type (legacy vs non-legacy) of the network being created.

This aligns with my thinking as well. As I understand, it's the presence (null vs not null) of the value that controls the type of network: as long as the value is non-empty, e.g. it's either true or false, the network is VPC (e.g. non-legacy).

To sum up a bit:

slevenick commented 3 years ago

Ok, looks like the cloud console confirms that you can go from true -> false without recreation, but not from false -> true.

Should be implementable via a customize diff to ForceNew only in one direction