_This issue was originally opened by @mcraig88 as hashicorp/terraform#16971. It was migrated here as a result of the provider split. The original body of the issue is below._
When using an ALB of type Network, an error is thrown stating that "Network Load Balancers do not support Stickiness" ( I did not define stickiness ). It looks like Stickiness is enabled by default.
When providing the stickiness block as below, I now get another error
v.0.11.1
...
resource "aws_lb_target_group" "serviceLoadBalancer-nlb-targetGroup" {
count = "${lookup(map("true", 0, "false", 1), var.ssl_passthrough_enabled)*(var.load_balancer_type == "network" ? 1 : 0)}"
name = "${var.elb_name_prefix}-elb-target"
port = "${var.service_host_http_port}"
protocol = "TCP"
vpc_id = "${lookup(module.defaultVars.vpc_ids, format("%s.%s", var.aws_account_alias, var.aws_region))}"
deregistration_delay = "${var.target_group_deregistration_delay}"
stickiness {
type = "lb_cookie"
enabled = false
}
}
...
Error: Error running plan: 1 error(s) occurred:
module.ecs-http-service.aws_lb_target_group.serviceLoadBalancer-nlb-targetGroup: 1 error(s) occurred:
module.ecs-http-service.aws_lb_target_group.serviceLoadBalancer-nlb-targetGroup: Network Load Balancers do not support Stickiness
When ALB type of Network, then stickiness should default to false.
Stickiness defaults to true.
Please list the full steps required to reproduce the issue, for example:
terraform init
terraform apply
I have manually created NLB with exact configuration as shown below and it is working fine.
However, with terraform I am also having the same issue as reported..
By documentation,
Now, when creating Network Load Balancer, stickiness is still enabled by default.
And it cannot be disabled because following block is not supported for NLB.
**stickiness {
type = "lb_cookie"
enabled = false
}**
Below is my terraform script and the problem is reproducible.
resource "aws_lb" "nlb" {
load_balancer_type = "network"
internal = false
subnets = ["${var.public_subnets_id}"]
enable_deletion_protection = false
}
resource "aws_lb_target_group" "nlb" {
port = 8080
protocol = "TCP"
vpc_id = "${var.vpc_id}"
target_type = "ip"
}
resource "aws_lb_target_group_attachment" "nlb" {
availability_zone = "all"
target_group_arn = "${aws_lb_target_group.nlb.arn}"
target_id = "${var.host}"
port = "${var.port}"
}
resource "aws_lb_listener" "nlb" {
load_balancer_arn = "${aws_lb.nlb.arn}"
port = 8080
protocol = "TCP"
"default_action" {
target_group_arn = "${aws_lb_target_group.nlb.arn}"
type = "forward"
}
}
+1 for me
Hi @dhumraketu - this is an unfortunate set of defaults which will likely need to be revisited at some point. I'll leave that one to a HashiCorp employee however, since it will likely involve a breaking change.
I am not getting this problem and can create NLBs no problem. The differences I see are
subnet_mapping
blocks rather than subnets
Could be the issue is tied to IP targets?
Terraform v0.11.1
+ provider.aws v1.6.0
Workaround:
stickiness = []
Example:
resource "aws_lb_target_group" "nlb" {
port = 8080
protocol = "TCP"
vpc_id = "${var.vpc_id}"
stickiness = []
}
Thanks @ykrevnyi. That worked for me.
Hey all, just an update on this and sorry for the delay in fixing!
So I could not reproduce this using the config here, but I think the core of the problem (judging from the output in the original issue) is that the current validation method for stickiness
in ensuring that on TCP target groups, that the block is not present _at all_, is making this resource tough to write modules for (you would pretty much have to declare the block twice).
enabled
attribute of the stickiness block, which helps matters, but still does not fix them 100% as if the block is declared, the data is still added to the API request, which gets rejected because TCP target groups do not support stickiness.In the spirit of moving this along I have added a commit to #2954 that fixes this, and adds tests and documentation. I want to get more eyes on this from members of the team here that are generally on the AWS provider the most, and then hopefully we can get it merged.
Thanks for your patience on this one and sorry for the delay!
The fix for this has been merged into master and will be released in v1.10.0, which I'll be cutting very shortly. Thanks for your patience and the fixes by @mattgiles and @vancluever!
terraform-provider-aws_v1.10.0_x4
stickiness = []
->
stickiness.#: "1" => "0"
stickiness.0.cookie_duration: "" => "86400"
stickiness.0.enabled: "" => "true"
@bflad @mattgiles @vancluever The issue still exists in v1.10.0 unfortunately.
resource "aws_lb_target_group" "ampelmann-terminator-tcp-80" {
name = "${var.pool_name}-tcp-80"
port = 80
protocol = "TCP"
vpc_id = "${var.vpc_id}"
health_check {
protocol = "HTTP"
port = 8081
path = "/health"
matcher = "200-399" # do not change
timeout = 6 # do not change
}
tags {
Name = "${aws_lb.ampelmann-terminator.name} - TCP:80"
Contact = "${var.contact}"
}
}
* module.ampelmann.aws_lb_target_group.ampelmann-terminator-tcp-80: 1 error(s) occurred:
* module.ampelmann.aws_lb_target_group.ampelmann-terminator-tcp-80: Network Load Balancers do not support Stickiness
$ terraform version
Terraform v0.11.3
+ provider.aws v1.10.0
+ provider.external v1.0.0
Did you try setting the stickiness block but to disabled?
Thanks, that works. I assumed that the fix won't longer enable stickiness by default for network load balancers, but I guess I was mistaken.
The workaround that worked for me was:
stickiness {
enabled = false
type = "lb_cookie"
}
Commenting this issue as it is occurring with the current Terraform and none of the described workarounds work for me.
Terraform v0.12.10 provider.aws v2.32.0
resource "aws_lb_target_group" "tg_web" {
name = "${var.name}"
port = "${var.port}"
protocol = "${var.protocol}"
vpc_id = "${var.vpc_id}"
stickiness = []
}
produces below error:
An argument named "stickiness" is not expected here. Did you mean to define a
block of type "stickiness"?
If I define block stickiness as such:
resource "aws_lb_target_group" "tg_web" {
name = "${var.name}"
port = "${var.port}"
protocol = "${var.protocol}"
vpc_id = "${var.vpc_id}"
stickiness {
enabled = false # stickiness not supported in NLB
type = "lb_cookie"
}
}
I get:
Error: Error modifying Target Group Attributes: InvalidConfigurationRequest: The provided target group attribute is not supported
status code: 400, request id: d52a5f5c-a967-478c-a902-7d70185d8625
on ../../modules/tg/main.tf line 4, in resource "aws_lb_target_group" "tg_web":
4: resource "aws_lb_target_group" "tg_web" {
I have contacted AWS support and they verified that AWS API is receiving the following:
"eventTime": "2019-10-13T17:38:11Z",
"eventSource": "elasticloadbalancing.amazonaws.com ",
"eventName": "ModifyTargetGroupAttributes",
"awsRegion": "eu-west-1",
"sourceIPAddress": "xxx",
"userAgent": "aws-sdk-go/1.25.4 (go1.13; linux; amd64) APN/1.0 HashiCorp/1.0 Terraform/0.12.10 (+https://www.terraform.io)",
"errorCode": "InvalidConfigurationRequestException",
"errorMessage": "The provided target group attribute is not supported",
"requestParameters": {
"attributes": [
{
"value": "300",
"key": "deregistration_delay.timeout_seconds"
},
{
"value": "false",
"key": "stickiness.enabled"
},
{
"value": "lb_cookie",
"key": "stickiness.type"
},
{
"value": "86400",
"key": "stickiness.lb_cookie.duration_seconds"
}
],
"targetGroupArn": "arn:aws:elasticloadbalancing:eu-west-1:5xx9883:targetgroup/prod-wp-https-tg/5cfdfxx784aacc"
},
TCP/TLS target groups cannot have "stickiness" attribute hence the error.
Finally, if I don't include stickiness argument or block, I get:
Error: Network Load Balancers do not support Stickiness
on ../../modules/tg/main.tf line 4, in resource "aws_lb_target_group" "tg_web":
4: resource "aws_lb_target_group" "tg_web" {
Which looks like stickiness is enabled by default by Terraform.
Does anyone have a solution for 2019?
Cheers
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!
Most helpful comment
Workaround:
Example: