Instance ID's shifted a spot (Using count)

[hashibot]

This issue was originally opened by @markmaas as hashicorp/terraform#6392. It was migrated here as part of the provider split. The original body of the issue is below.

---

Dear Reader,

Because I was running into this problem:
hashicorp/terraform#6391

I refactored my terraform code using this elb setup:

# ELB
resource "aws_elb" "nvb" {
  name = "dev-nvb-elb"
  subnets = ["${split(",", module.vpc.public_subnets)}"]

  listener {
    instance_port = 80
    instance_protocol = "http"
    lb_port = 80
    lb_protocol = "http"
  }

  instances = ["${split(",", aws_instance.haproxy.*.id)}"]
  cross_zone_load_balancing = true
  idle_timeout = 400
  connection_draining = true
  connection_draining_timeout = 400

  tags {
    Name = "dev-nvb-elb"
    Env = "development"
  }
}

and this instance setup:

# Public side
resource "aws_instance" "haproxy" {
    ami = "${lookup(var.aws_amis, var.aws_region)}"
    instance_type = "t1.micro"
    key_name = "${aws_key_pair.ansible_bootstrap.id}"
    subnet_id = "${element(split(",", module.vpc.public_subnets), count.index)}"
    count = 1
    tags {
        Name = "haproxy-${count.index}"
        Env = "development"
    }
}

Where public_subnets comes from the vpc module I wrote:

output:

output "public_subnets" {
  value = "${join(",", aws_subnet.public.*.id)}"
}

main:

resource "aws_subnet" "public" {
  vpc_id = "${aws_vpc.mod.id}"
  cidr_block = "${lookup(var.public_blocks, concat("zone", count.index))}"
  availability_zone = "${lookup(var.zones, concat("zone", count.index))}"
  map_public_ip_on_launch = true
  count = "${var.public_count}"
}

And a zones / blocks variable like this:

variable "zones" {
    default = {
        zone0 = "eu-west-1a"
        zone1 = "eu-west-1b"
        zone2 = "eu-west-1c"
    }
}

variable "public_blocks" {
  type = "map"
  default = {
    zone0 = "10.21.101.0/24"
    zone1 = "10.21.102.0/24"
    zone2 = "10.21.103.0/24"
  }
}

When creating this thing, this variable instances = ["${split(",", aws_instance.haproxy.*.id)}"] get's filled corectly, except it seems to shift all the instance id's. So that spot number "0" is empty. This then results in the following error:

aws_instance.haproxy: Creation complete
aws_elb.nvb: Modifying...
  connection_draining:         "0" => "1"
  connection_draining_timeout: "300" => "400"
  cross_zone_load_balancing:   "0" => "1"
  idle_timeout:                "60" => "400"
  instances.#:                 "0" => "2"
  instances.0:                 "" => ""
  instances.791602850:         "" => "i-972d7d1f"
Error applying plan:

1 error(s) occurred:

* aws_elb.nvb: Failure registering instances with ELB: ValidationError: Instance cannot be empty.
        status code: 400, request id: 51f8f36b-0d3b-11e6-9e7c-dd19a12be914

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Any idea how I could shift those id's back one spot?

Thanks,
Mark

Terraform Version

Terraform v0.6.15

Affected Resource(s)

Please list the resources as a list, for example:

• aws_instance
• aws_elb

Expected Behavior

To have all the instances added to the elb

Actual Behavior

Terraform stops with an error saying it cannot add an empty instance id

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[ghost]

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!