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

lb_target_group not compatible with aws_lb of type network #1912

Closed
fawzyj opened this issue Oct 16, 2017 · 22 comments · Fixed by #2251
Closed

lb_target_group not compatible with aws_lb of type network #1912

fawzyj opened this issue Oct 16, 2017 · 22 comments · Fixed by #2251
Labels
enhancement Requests to existing resources that expand the functionality or scope.

Comments

@fawzyj
Copy link

fawzyj commented Oct 16, 2017

Using AWS provider 1.1

I cannot create lb_target_goup for aws_lb of type "network"
I want to create a network load balancer to balance some tcp connection, but when i set the aws_lb_target_group protocol to 'tcp' I got the following error:

aws_lb_target_group.tg: "protocol" must be either "HTTP" or "HTTPS"

The code:

resource "aws_lb" "ecs_lb" {
  name            = "ecs-lb"
  load_balancer_type = "network"
  subnets         = ["${aws_subnet.public.*.id}"]
  security_groups = ["${aws_security_group.lb_sg.id}"]
}

resource "aws_lb_target_group" "application_tg" {
  name     = "application_tg"
  port     = 80
  protocol = "tcp"
  vpc_id   = "${aws_vpc.main.id}"
}
@radeksimko radeksimko added the enhancement Requests to existing resources that expand the functionality or scope. label Oct 16, 2017
@briankohler
Copy link

This should be marked as a bug. It makes network load balancers unusable, and I can only assume it's supposed to be a working feature since it's referenced in the documentation.

@rrueth
Copy link

rrueth commented Oct 16, 2017

I'm seeing the same error as @fawzyj. I agree with @briankohler that this should be a bug. Without being able to create the TCP target group, you cannot create a complete Network Load Balancer in Terraform.

@aandriyc
Copy link

+1 same issue, and this is also true for health checks, as it gives this error:
"health_check.0.protocol" must be either "HTTP" or "HTTPS"

@ccovarru
Copy link

+1 Confirming issue as well.

@Ginja
Copy link

Ginja commented Oct 17, 2017

Should be addressed by #1884

@code4mankind
Copy link

+1 Definitely a bug, not an enhancement - aws_lb of type "network" is unusable, unable to create aws_lb_listener with "TCP" protocol.

@aandriyc
Copy link

Looks like there are more changes needed. Even if you build AWS provider with the changes above (#1884), NLB resource still fails with this message:
Failure Setting ALB Subnets: InvalidConfigurationRequest: SetSubnets is not supported for load balancers of type 'network'
status code: 400, request id: 4c173a71-b36c-11e7-9ffb-4f8e5bd294fa
Note though, that NLB is created anyway and looks valid. And further Terraform plan / apply shows everything as up to date.

Trying to create NLB with subnet_mapping blocks instead of subnets list just hangs indefinitely

@joseph-holland
Copy link

Yes, more changes are required. I had opened a duplicate issue by accident (#1944).

Protocol
The protocol to use for routing traffic to the targets. For Application Load Balancers, the supported protocols are HTTP and HTTPS. For Network Load Balancers, the supported protocol is TCP.
Type: String
Valid Values: HTTP | HTTPS | TCP
Required: Yes

  • resource_aws_lb_target_group.go
    Saw when checking the source that even though the new Network LBs are supported the code to check the protocol was not updated. This also seems to be the case with the health check code too.
421 func validateAwsLbTargetGroupProtocol(v interface{}, k string) (ws []string, errors []error) {
422  	protocol := strings.ToLower(v.(string))
423  	if protocol == "http" || protocol == "https" {
424  		return
425  	}
426  
427  	errors = append(errors, fmt.Errorf("%q must be either %q or %q", k, "HTTP", "HTTPS"))
428  	return
429  }

@briankohler
Copy link

Not sure if this should be covered too, but NLBs (and maybe ALBs, I'm not sure off the top of my head) can now accept either an IP address or an InstanceID as targets. I've confirmed that doesn't work on on any branches, and it seems that feature is not trivial to incorporate.

@bploetz
Copy link

bploetz commented Oct 19, 2017

I'm not sure if this is related or not, but the aws_lb Data Source doesn't seem to work with Network Load Balancers either.

I created two load balancers manually in the AWS console: one Network Load Balancer, one Application Load Balancer. When I try to reference the Network Load Balancer in an aws_lb Data Source, I get this error:

data "aws_lb" "test" {
  arn = "arn:aws:elasticloadbalancing:us-west-2:XXXXXXXXXX:loadbalancer/net/test/XXXXXXXXXXX"
}

terraform plan:

Error refreshing state: 1 error(s) occurred:

* module.aws_test.data.aws_lb.test: 1 error(s) occurred:

* module.aws_test.data.aws_lb.test: data.aws_lb.test: Error retrieving LB: LoadBalancerNotFound: One or more load balancers not found
	status code: 400, request id: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

However when I plug in the ARN of the Application Load Balancer to the aws_lb Data Source, it works just fine.

I can obviously split this into a separate issue if need be, just let me know.

@korjik
Copy link

korjik commented Oct 24, 2017

I don't think that SetSubnets issue was resolved in any mentioned issues above. The error is mentioned, but I don't see any fixes for this exact problem.

When using config:

resource "aws_lb" "nlb" {
  name                = "${var.nlb_name}"
  load_balancer_type  = "network"
  internal            = true
  subnets             = ["${var.subnet_ids}"]
}

We receive:

* aws_lb.nlb: Failure Setting ALB Subnets: InvalidConfigurationRequest: SetSubnets is not supported for load balancers of type 'network'
	status code: 400, request id: 6fbf4ef2-b8d6-11e7-a30b-cd396b848124

subnets is a valid method for create-load-balancer type network: http://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-cli.html

NLB is created, but the error is annoying.

@zihaoyu
Copy link

zihaoyu commented Oct 25, 2017

Not only is the protocol field of aws_lb_target_group resource affected, but also the health_check protocol. I'm seeing two errors with my Network LB with TCP healthcheck:

* module.my_module.aws_lb_target_group.master: "health_check.0.protocol" must be either "HTTP" or "HTTPS"
* module.my_module.aws_lb_target_group.master: "protocol" must be either "HTTP" or "HTTPS"

@OferE
Copy link

OferE commented Nov 1, 2017

Using aws version 1.2 - this problem still remains.
Network load balancer are not usable because of it.
This is critical - when can we expect this fix?

@farvour
Copy link

farvour commented Nov 2, 2017

@OferE the worst part is it clearly wasn't even tested, because setting a target attachment would have failed immediately since NLBs only support TCP protocols as far as I know. Even worse it made it to the Terraform documentation. This is definitely a blocker for using this feature.

@mminks
Copy link

mminks commented Nov 3, 2017

+1

3 similar comments
@fterrier
Copy link

fterrier commented Nov 3, 2017

+1

@Gephorian
Copy link

+1

@nvenky
Copy link

nvenky commented Nov 6, 2017

+1

@Ehekatl
Copy link

Ehekatl commented Nov 6, 2017

@radeksimko can you mark this as bug? It's been long time since the nlb support released, but it's completely broken. There are some pending fixes already: #1884

@akafrmn
Copy link

akafrmn commented Nov 7, 2017

+1

1 similar comment
@ghost
Copy link

ghost commented Nov 7, 2017

+1

@hashicorp hashicorp locked and limited conversation to collaborators Nov 7, 2017
@radeksimko
Copy link
Member

radeksimko commented Nov 7, 2017

I will be taking a look into it this week, there's a couple of pending PRs.

This is not a bug, because we never claimed anywhere NLB was fully supported (just that a single resource aws_lb supports it) and the validation error clearly says it expects HTTP or HTTPS - thus it's not supported yet and it's labelled as enhancement.


FYI: Reactions are the right way to express interest as they're also used in sorting, +1 comments generate notifications which is usually not helpful in the context of other comments. Thanks to all the people who used reactions.

I just locked this thread to avoid further notifications. I'm well aware this also prevents people from using reactions, but there's no way to only lock comments on Github, unfortunately.

Thanks for understanding.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope.
Projects
None yet
Development

Successfully merging a pull request may close this issue.