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

Existing google_compute_interconnect_attachment causing plan to fail #8791

Assignees
Labels

Comments

@robertb724
Copy link

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 version: v0.12.29
google provider version: "v3.62.0"

Affected Resource(s)

  • google_compute_interconnect_attachment

Terraform Configuration Files

resource "google_compute_interconnect_attachment" "default" {
  count = length(var.interconnect_regions) * length(local.availability_domains)

  name = format("%s-%s-%s-eq-sw%02d-partner-router-%02d",
    var.name_prefix,
    var.environment,
    local.region_onprem_map[var.interconnect_regions[floor(count.index / length(local.availability_domains))]],
    (count.index%length(local.availability_domains)) + 1,
    (count.index%length(local.availability_domains)) + 1)
  type = "PARTNER"
  router = google_compute_router.interconnect[count.index].self_link
  region = var.interconnect_regions[floor(count.index / length(local.availability_domains))]
  edge_availability_domain = local.availability_domains[count.index % length(local.availability_domains)]

  lifecycle {
    prevent_destroy = true
  }
}

Debug Output

Error: A number is required

Panic Output

Expected Behavior

No Changes: Infrastructure is up to date

Actual Behavior

Terraform plan errors without code change with error Error: A number is required

Steps to Reproduce

  1. terraform plan

Important Factoids

We do not explicitly set our provider, after the release of v3.62.0 our terraform fails during the plan with Error: A number is required . The error does not indicate any line number and is repeated four times. After looking at the release notes for v3.62.0 I see the change in data type for the mtu field on the interconnect resource and connect the dots since we have 4 interconnect attachments. We do not set the mtu field and are using the default. If I pass 1440 as an int we still get the error.

References

@ghost ghost added the bug label Mar 29, 2021
@venkykuberan venkykuberan self-assigned this Mar 30, 2021
@venkykuberan
Copy link
Contributor

@robertb724 I am able to create the resource successfully with similar config as yours
terraform version

+ provider registry.terraform.io/hashicorp/google v3.62.0
+ provider registry.terraform.io/hashicorp/google-beta v3.54.0
+ provider registry.terraform.io/hashicorp/random v3.1.0
resource "google_compute_interconnect_attachment" "default" {
  name                     = "interconnect"
  router                   = google_compute_router.foobar.self_link
  region                   = var.region
  edge_availability_domain = "AVAILABILITY_DOMAIN_1"
  type                     = "PARTNER"
}

resource "google_compute_router" "foobar" {
  name    = "myrouter"
  network = google_compute_network.foobar.name
  region                   = var.region
  bgp{
  asn = 64514
  }
}

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

Can you please check if the sample config works for you. We will take it from there .
However i do see the default value 1440 isn't set for mtu which is a bug, but that wouldn't cause the TF plan to fail

@robertb724
Copy link
Author

@venkykuberan I am able to create the resources with that configuration on both v3.61.0 and v3.62.0. However, if I create the resources with v3.61.0, change provider version to v3.62.0 and then run terraform plan I get Error: a number is required. If I try to set mtu to 1440 or "1440" I still get the error

➜  interconnect-test terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

google_compute_network.foobar: Refreshing state... [id=projects/my-project/global/networks/my-network]
google_compute_router.foobar: Refreshing state... [id=projects/my-project/regions/us-east1/routers/myrouter]

Error: a number is required

@venkykuberan
Copy link
Contributor

venkykuberan commented Mar 31, 2021

Yes that's due to the dat type change (string to int) in 3.62.0 from GoogleCloudPlatform/magic-modules#4601. Looks like that's breaking change. Also default value 1440 isn't being assigned to mtu when its absent in config. We will work on it. Thank you for filing.

@ghost
Copy link

ghost commented May 3, 2021

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators May 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.