Plan fails when a resource depends on google_compute_address

[juicemia]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.3.0
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v4.2.1
+ provider registry.terraform.io/hashicorp/http v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0

Affected Resource(s)

• google_compute_address
• google_compute_firewall

Terraform Configuration Files

resource "google_compute_address" "this" {
  count = 2
  name  = "nat-${count.index}"
}

resource "google_compute_firewall" "this" {
  name        = "allow-nat"
  network     = data.google_compute_network.thing.self_link
  description = "Allow the NAT IP's."

  target_service_accounts = [data.google_service_account.thing.email]
  source_ranges           = google_compute_address.this[*].address
  allow {
    protocol = "tcp"
    ports    = ["8080"]
  }
}

Debug Output

Panic Output

Expected Behavior

Terraform should have been able to create a plan with a firewall that depends on agoogle_compute_address.

The plan should show the following for the firewall (this was taken using module version 3.90.1):

      + source_ranges           = (known after apply)

Actual Behavior

Terraform fails to create a plan with the following error:

╷
│ Error: 1 error occurred:
│ 	* one of source_tags, source_ranges, or source_service_accounts must be defined
│
│
│
│   with google_compute_firewall.this,
│   on networking.tf line 116, in resource "google_compute_firewall" "this":
│  116: resource "google_compute_firewall" "this" {
│
╵

Steps to Reproduce

1. terraform plan

Important Factoids

References

• #0000

[juicemia]

For anybody who might also be having this issue, downgrading to 3.90.1 will get a successful plan. Downgrading to 4.0.0 gets the same error.

[juicemia]

Running plan with the provider on 4.0.0 will work if the address is specified on the google_compute_address resource like this:

resource "google_compute_address" "this" {
  count   = 1
  name    = "nat-${count.index}"
  address = "192.169.1.0"
}

However, this doesn't solve my use case because I'm using this address for a cloud NAT, so it needs to be a public external address, which means I have to leave the address field blank.

[edwardmedia]

@juicemia Looks like below change is directly related. It is a breaking-change. What you were experiencing is expected. But from a fresh config, I can't repro. Does this make sense?

#2924

[juicemia]

It doesn't make sense to me because using version 3.90.1 correctly fills in values for that required field.

When terraform plan is run using that provider version I can see that the source_ranges requirement is fulfilled, and it's value is (known after apply) because the google_compute_address hasn't actually been created yet. When upgrading to provider version 4.x somehow the provider is now failing to satisfy the requirement. This isn't what I would expect to experience according to the docs of what the expected behavior should be. I would expect the provider to still be able to correctly wire things up.

[edwardmedia]

@juicemia that is why it is called a breaking-change. An issue is expected. You may choose to keep v3.90.1 or delete the state and import the resource with new version. I agree it is not the optimal and we have done out best to minimize the impacts

[juicemia]

I'm sorry maybe I've been unclear about what exactly the issue is. The google_compute_firewall has a breaking change and it's documented: source_ranges is now required whereas it wasn't before.

The change you linked is breaking because it changes the API of google_compute_firewall in a way that will break people who were not setting any of the source_ parameters. What I'm reporting is a regression in the google_compute_address resource.

[edwardmedia]

@slevenick what do you think about this?

[slevenick]

If you apply the address first does it work? What are the actual values coming out of the .address value from that resource?

This is strange, because it seems like the address value coming out of the google_compute_address is empty, but I would imagine they do have values. Maybe because it's Optional+Computed there is plan-time unknownness that is being passed to the firewall resource?

[slevenick]

Oh, I believe this was fixed in GoogleCloudPlatform/magic-modules#5526

Upgrading to a newer version of the provider should fix it

[juicemia]

Running the latest module version has the same issue. I was doing this in a brand new project.

As soon as I get some time I'll try your suggestion of running google_compute_address first just to see what it's outputting.

[slevenick]

Running the latest module version has the same issue. I was doing this in a brand new project.

As soon as I get some time I'll try your suggestion of running google_compute_address first just to see what it's outputting.

You're seeing this with version 4.30+ of the provider?

[juicemia]

I see this on version 4.X of the provider.

[slevenick]

What version specifically?

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.