Terraform: Add a separate ELB listener resource - ie. aws_elb_listener.

[clstokes]

Currently (as of 0.7.8), ELB listeners are defined and managed as in-line _sub_-resources. This makes it very difficult to create modules for re-use as the number of listeners is static.

Terraform should support separate resources for listeners so that these can be made more modular and allow for meta-parameters on listeners - ie. aws_elb_listener. This is similar to the aws_elb_attachment and aws_security_group_rule resources that exist.

Current:

resource "aws_elb" "bar" {
   ...
  listener {
    instance_port = 8000
    instance_protocol = "http"
    lb_port = 80
    lb_protocol = "http"
  }
}

Proposed:

resource "aws_elb" "bar" {
}

resource "aws_elb_listener" "bar" {
  instance_port = 8000
  instance_protocol = "http"
  lb_port = 80
  lb_protocol = "http"
}

[dcloud9]

+1 so that ELB mods can be reused as per required number of listeners. AWS CLI already supports this
http://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-listeners.html

[stack72]

Hi @clstokes / @dcloud9

So I just started looking at this and noticed that you can't actually create an AWS ELB without a listener. Therefore, the issue here would be that if we create an aws_elb and give it listener 1, then create aws_elb_listener and attach it to the aws_elb then the next time the aws_elb would be checked by terraform it would show 2 listeners and try and move it to 1

This is what happens with security_group and security_group_rule

Thoughts on this?

P.

[dcloud9]

@stack72 Agree. ELB requires a min of 1 listener so we can assign it as listener 1 to begin with. Then increment numbers on adding more listeners.

[clstokes]

How does security_group and security_group_rule handle this? Is the "fake" listener removed when the first aws_elb_listener is added? Can the elb be created with a single listener and then immediately remove the one listener?

[dcloud9]

@stack72 I believe multiple listeners can be attach to single ELB (many to one), therefore loadbalancer_name(s) should be rather typeString, right?
Could this be the reason why TravisCI build is failing.
Here are some refs to single ELB
http://boto.cloudhackers.com/en/latest/ref/elb.html#module-boto.ec2.elb.listener
http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/ELB/Listener.html

@clstokes I think @stack72 is nearly there in the fix. My understanding is listener_1 will attach to ELB on creation of ELB resource, then elb_listener2 resource will attach as listener_2 and so on. Should we decide to remove listener_1, listener_2 would assume listener_1 in terms of numbering.
Correct me if wrong @stack72 .

[AdimUser]

Hi Team

This is worked for me

resource "aws_elb" "elb" {
name = "${var.elb_name}"
subnets = ["${var.subnet_ids}"]
internal = "${var.elb_is_internal}"
security_groups = ["${var.elb_security_group}"]

listener = [{ instance_port = 80 instance_protocol = "http" lb_port = 80 lb_protocol = "http"},{ instance_port = 8090 instance_protocol = "http" lb_port = 8090 lb_protocol = "http" }]

health_check {
healthy_threshold = 2
unhealthy_threshold = 2
timeout = 3
target = "${var.health_check_target}"
interval = 30
}
cross_zone_load_balancing = true
}

But I am failed to pass this list of maps as variables to the resource property..
Hope anyone here can help me to fix this..

Thank you!

[vemuri1256]

+1

[mambetica]

+1

[michalschott]

+1

[evanstoddard23]

+1

[tomhaynes]

+1

[ghost]

+1

[ekowcharles]

+1

[timotieto]

+1

[mattkenn4545]

Is there are update on the inclusion of this?

[ghost]

+1

[saurabh-hirani]

+1

[djl87]

+1

[mike-schiller]

+1

[soulston]

+1

Remember to update your ./modules/elb/variables.tf accordingly:

variable "aws_elb_listener" {
type = "list"
}

[blind3dd]

+1

[hashibot[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.