Terraform-provider-aws: Crash interacting with target groups for network load balancers

Created on 28 Mar 2018  ·  15Comments  ·  Source: hashicorp/terraform-provider-aws

Hi there,

I'm trying to create target groups for a network load balancer and terraform is crashing like in the output in Gist. Target groups for application load balancers works fine.
This behaviour started to occur two days ago, and, as of my knowledge, nothing changed in my environment.

Terraform Version

Terraform v0.11.5

  • provider.aws v1.12.0

Affected Resource(s)

  • aws_lb_target_group

Terraform Configuration Files

resource "aws_lb_target_group" "network-target-group" {
  name     = "network-target-group"
  port     = "1024"
  protocol = "TCP"
  vpc_id   = "${var.aws_vpc}"
}

Debug Output

Panic Output

https://gist.github.com/tiagowegner/552984c751b6b4c0a36b265e61c7b92c

Expected Behavior

Target group created, state update and successful terraform exit.

Actual Behavior

Target group created, state not updated and terraform crash.

Steps to Reproduce

  1. terraform apply
    Alternative:
  2. After crash, run terraform import aws_lb_target_group.network-target-group <target-group-arn>

Important Factoids

I'm running terraform behind a corporate proxy, using environment variables to set proxy address. I checked and it seems nothing is being blocked.

References

bug crash servicelbv2

Most helpful comment

FYI given the severity here, I think the right course of action will be to immediately release v1.13.0 of the AWS provider. I'll post an update very shortly.

All 15 comments

Hey @tiagowegner, your crash does not appear to be in the correct format. Can you take the output of the crash.log file and put in a gist, and update your issue?

Thanks!

I've just updated the issue. Sorry, bad link.

Relevant portion of crash log:

2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4: panic: runtime error: invalid memory address or nil pointer dereference
2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4: [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1d4e5da]
2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4: 
2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4: goroutine 120 [running]:
2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4: github.com/terraform-providers/terraform-provider-aws/aws.flattenAwsLbTargetGroupResource(0xc42059d260, 0x264d900, 0xc420202c80, 0xc4202e6510, 0x0, 0xc420444738)
2018-03-28T11:16:25.321-0300 [DEBUG] plugin.terraform-provider-aws_v1.12.0_x4:  /opt/teamcity-agent/work/222ea50a1b4f75f4/src/github.com/terraform-providers/terraform-provider-aws/aws/resource_aws_lb_target_group.go:468 +0x5fa

Looks like we're missing a nil check on targetGroup.Matcher:

https://github.com/terraform-providers/terraform-provider-aws/blob/ee46cf969e99d423cd58907f7c51b246a2256506/aws/resource_aws_lb_target_group.go#L468

Interesting that this hasn't been caught by the existing acceptance test TestAccAWSLBTargetGroup_networkLB_TargetGroup

Ha so using some 🕵️ from the crash log, its reproducible in sa-east-1, but not in us-west-2. AWS might be trying a new service release in that region (or its running an older service). Bug fix submitted: #3954

The fix for this has been merged into master and will release with v1.13.0 of the AWS provider, likely in about a week.

@bflad this issue is blocking us. Would you cherry-pick it off of the commit for 1.12.0 and release it as 1.12.1?

edit: also, thank you for the quick fix. 3 hours from report to fix 👏

we are running into this as well.

FYI given the severity here, I think the right course of action will be to immediately release v1.13.0 of the AWS provider. I'll post an update very shortly.

v1.13.0 binaries are uploaded and a quick smoke test of this issue shows it working as expected for me.

We were hitting this issue as well. Initial test of v1.13.0 seem to be working. Thanks @bflad for the quick turnaround on this!

Seems to be working for me as well — 💯 👍 for the quick turnaround — greatly appreciated!

Thanks! Working in our environment, appreciate the quick turnaround!

Working here in sa-east-1 too! Thanks a lot!

Thank you everyone for the hard work here. We were also seeing this behavior and scratching our heads. Once I dug into the source the nil error was easy to see. My question though is understanding why this changed within AWS? How would AWS testing a new service be related for example?

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. Thanks!

Was this page helpful?
0 / 5 - 0 ratings