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}"
}
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.
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.
+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"
+1 Confirming issue as well.
Should be addressed by #1884
+1 Definitely a bug, not an enhancement - aws_lb of type "network" is unusable, unable to create aws_lb_listener with "TCP" protocol.
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
Yes, more changes are required. I had opened a duplicate issue by accident (#1944).
AWS Network LB API docs specify that HTTP, HTTPS or TCP protocols are accepted values:
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 }
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.
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.
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.
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"
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?
@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.
+1
+1
+1
+1
@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
+1
+1
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.
Most helpful comment
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?