panic: interface conversion: interface is nil, not string

[vaygr]

Terraform Version

0.7.1. Under 0.7.0 it works just fine.

Affected Resource(s)

• google_compute_firewall

Terraform Configuration Files

The google_compute_firewall resource is simple enough and contains just 2 rules to allow incoming ports to specific instances marked by tags.

Debug Output

http://sprunge.us/fCWA

All sensitive information has been removed.

Steps to Reproduce

1. terraform plan -target "module.firewall_gce"

References

This might be the cause or related:

• "Unexpected EOF" and "connection is shut down" with google providers when using terraform 0.7.1 #8341

[cblecker]

Hi @vaygr!
Is it possible to provide more details around your terraform config? I just tried to duplicate this with the following, and it both planned and applied successfully:

main.tf:

variable "project_name" {
  description = "The ID of the Google Cloud project"
}

provider "google" {
  region      = "us-central1"
  project     = "${var.project_name}"
  credentials = ""
}

module "firewall_gce" {
  source = "./firewall_gce"
}

firewall_gce/main.tf:

resource "google_compute_firewall" "default1" {
  name    = "tf-firewall1"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["test-www-node1"]
}

resource "google_compute_firewall" "default2" {
  name    = "tf-firewall2"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["8080"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["test-www-node2"]
}

resource "google_compute_firewall" "default3" {
  name    = "tf-firewall3"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["test-www-node3"]
}

From what I can see "unexpected EOF" usually relates to an issue with your local system communicating with the provider's API. Also, what OS/arch are you running on your local system (uname -a)? I'm using Mac OS X 10.11.6 (Darwin x86_64).

[vaygr]

@cblecker what if you try to apply that with 0.7.0 and then plan with 0.7.1?

[cblecker]

Yup. Confirmed I get the same panic when I apply the config with v0.7.0, update terraform to v0.7.1, and then run a plan.

Figuring this has something to do with the state files, here's a diff on what my state looks like after a v0.7.0 apply, vs what it looks like after a fresh v0.7.1 apply: https://gist.github.com/cblecker/6837b659f2700735277057257cf48638

[cblecker]

Okay, getting a bit closer. Creating a new build of v0.7.1 but reverting 09df0ef seems to work. Was directed to this commit by the following lines in the panic:

2016/08/20 09:03:23 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/builtin/providers/google.convertStringArr(0xc420538240, 0x2, 0x2, 0xc4204aeda0, 0xc4202e1948, 0x1)
2016/08/20 09:03:23 [DEBUG] plugin: terraform:  /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/google/resource_compute_target_pool.go:94 +0xc0
2016/08/20 09:03:23 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/builtin/providers/google.resourceComputeFirewallAllowHash(0x279d400, 0xc42032cf00, 0xc4205380f8)
2016/08/20 09:03:23 [DEBUG] plugin: terraform:  /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/google/resource_compute_firewall.go:109 +0x271

It looks like the state migration that is supposed to happen per #8236, isn't working as intended.

cc: @nwwebb as the author of the commit in question

[jen20]

Hmm this is nasty, we'll look at fixing it up tomorrow. We are planning a 0.7.2 in fairly short order anyway, and will ensure this is resolved in that. Thanks for the detailed reproduction, it should make this reasonably straightforward to fix.

[nwwebb]

Sorry about that, thank you for the fix @jen20!

[asbjornenge]

I'm running into this error for (probably) some other target...?

Works fine with 0.7.0 (version used for apply), but fails for 0.7.1 and all subsequent versions (tried all up to 0.7.6).

crash.log

//cc @jen20

[cblecker]

@asbjornenge: As this issue is closed, you may wish to open a new issue and then reference this one. There may have been a regression somewhere.

[ghost]

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.