Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"diffs didn't match during apply" with google_compute_firewall #1073

Closed
julienvey opened this issue Feb 27, 2015 · 8 comments · Fixed by #1082
Closed

"diffs didn't match during apply" with google_compute_firewall #1073

julienvey opened this issue Feb 27, 2015 · 8 comments · Fixed by #1082

Comments

@julienvey
Copy link
Contributor

Tested with 0.3.7 and last version from master

The following tf file causes the diffs didn't match during apply error when running terraform apply

resource "google_compute_network" "subnet_1" {
    name = "subnet-test"
    ipv4_range = "10.0.0.0/24"
}

resource "google_compute_firewall" "test" {
  name = "test-1080"
  network = "${google_compute_network.subnet_1.name}"
  source_ranges = ["${google_compute_address.test_addr.address}/32"]
  allow {
    protocol = "tcp"
  }
}

resource "google_compute_address" "test_addr" {
    name = "test-addr"
}

The full log of the command http://pastebin.com/RgncfeZU

Running terraform apply a second time works well http://pastebin.com/16PdNUFL

However, if I remove the dependency between google_compute_firewall and google_compute_address, there is no error

resource "google_compute_network" "subnet_1" {
    name = "subnet-test"
    ipv4_range = "10.0.0.0/24"
}

resource "google_compute_firewall" "test" {
  name = "test-1080"
  network = "${google_compute_network.subnet_1.name}"
  source_ranges = ["1.1.1.1/32"]
  allow {
    protocol = "tcp"
  }
}

The log of the command http://pastebin.com/4PEuWdKq

@erjohnso
Copy link

/cc @sparkprime

@sparkprime
Copy link
Contributor

First impression is this looks very similar to #634

@sparkprime
Copy link
Contributor

@mitchellh thoughts?

@sparkprime
Copy link
Contributor

There is also no error if you remove the dependency on the network (by using the "default" network instead)

@mitchellh
Copy link
Contributor

I haven't had a chance to look at this yet but its certainly a core issue. Tagged accordingly and we'll make sure to take a look very soon.

@mitchellh
Copy link
Contributor

Reproduced.

Personal notes so far: The diff isn't properly detecting the set as computed. It is showing up like this (important line): source_ranges.1902308426: "" => "74D93920-ED26-11E3-AC10-0800200C9A66/32". This should show up as source_ranges.1902308426: "" => "<computed>" or something CLOSE to that.

@mitchellh
Copy link
Contributor

Fixed by #1082 once merged.

@ghost
Copy link

ghost commented May 4, 2020

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.

@ghost ghost locked and limited conversation to collaborators May 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants