strconv.ParseInt invalid syntax #5254

scalp42 · 2016-02-22T20:33:29Z

Using Terraform v0.6.12-dev (e70516a), we're now getting a syntax error:

terraform apply terraform
Error applying plan:

1 error(s) occurred:

* Error reading aws_subnet.infra-public count: strconv.ParseInt: parsing "${var.infra_count}": invalid syntax

This is the config:

variable "infra_count" {
  description = "Count index for all the things"
  default = 3
}

resource "aws_subnet" "infra-public" {
  count = "${var.infra_count}"
  vpc_id                  = "${aws_vpc.infra.id}"
  availability_zone       = "${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
  cidr_block              = "${lookup(var.infra_public_subnet_cidr_blocks, count.index)}"
  map_public_ip_on_launch = true
  depends_on              = ["aws_internet_gateway.infra-igw"]
  tags {
    Name = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
    Description = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
    vpc = "infra"
    terraform = "true"
  }
}

Git blame:

d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 11) resource "aws_subnet" "infra-public" {
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 12)   count = "${var.infra_count}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 13)   vpc_id                  = "${aws_vpc.infra.id}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 14)   availability_zone       = "${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 15)   cidr_block              = "${lookup(var.infra_public_subnet_cidr_blocks, count.index)}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 16)   map_public_ip_on_launch = true
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 17)   depends_on              = ["aws_internet_gateway.infra-igw"]
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 18)   tags {
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 19)     Name = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 20)     Description = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 21)     vpc = "infra"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 22)     terraform = "true"
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 23)   }
d71c2a2c (Anthony Scalisi 2015-07-02 22:49:36 -0700 24) }


8261d4fb (Anthony Scalisi 2015-07-02 22:49:20 -0700  1) variable "infra_count" {
8261d4fb (Anthony Scalisi 2015-07-02 22:49:20 -0700  2)   description = "Count index for all the things"
8261d4fb (Anthony Scalisi 2015-07-02 22:49:20 -0700  3)   default = 3
8261d4fb (Anthony Scalisi 2015-07-02 22:49:20 -0700  4) }

Error was not happening up to 5748487

Any ideas ?

The text was updated successfully, but these errors were encountered:

phinze · 2016-02-23T14:38:26Z

Hi @scalp42 - this is definitely odd. It might also have to do with #4795 which has more of a diff in the area and was merged around the same time.

I'm trying to reproduce on this side and not having any luck. Can you spot any differences between the config below and yours that might be key to reproducing the issue?

Also: does the syntax error happen every time or only sporadically?

If you could gist up your debug log (scrubbed of any sensitive information) when you hit the error that would be helpful as well.

variable "region" {
  default = "us-west-2"
}

variable "infra_count" {
  default = 3
}

variable "infra_public_subnet_cidr_blocks" {
  default = {
    "0" = "10.0.1.0/24"
    "1" = "10.0.2.0/24"
    "2" = "10.0.3.0/24"
  }
}

variable "infra_subnet_availability_zones" {
  default = {
    "0" = "a"
    "1" = "b"
    "2" = "c"
  }
}

resource "aws_vpc" "infra" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_internet_gateway" "infra-igw" {
  vpc_id = "${aws_vpc.infra.id}"
}

resource "aws_subnet" "infra-public" {
  count                   = "${var.infra_count}"
  vpc_id                  = "${aws_vpc.infra.id}"
  availability_zone       = "${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
  cidr_block              = "${lookup(var.infra_public_subnet_cidr_blocks, count.index)}"
  map_public_ip_on_launch = true
  depends_on              = ["aws_internet_gateway.infra-igw"]
  tags {
    Name = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
    Description = "infra-public-${concat(var.region, lookup(var.infra_subnet_availability_zones, count.index))}"
    vpc = "infra"
    terraform = "true"
  }
}

scalp42 · 2016-02-23T19:18:57Z

Thanks for the quick answer @phinze

As of right now I can reproduce it all the time on any terraform apply (so currently blocked unless using 5748487):

This gist contains the steps that got me there:

set desired capacity to 1 in AWS by hand (dont think it's related)
bump desired capacity from 0 to 2 in terraform config (explains maybe why it's a weird diff)
ran terraform plan
ran terraform apply which led to syntax error

I just sent you the trace log by 📧 💌 (address listed on your Github profile).

phinze · 2016-02-23T19:35:32Z

(Got the log in email, will analyze to help cook up a repro case.)

Noting here that you can workaround the issue by temporarily inlining the value of infra_count, which should unblock you.

phinze · 2016-02-23T21:41:53Z

Okay got a repro here (assumes region: us-west-2).

Config

variable "infra_count" {
  default = 3
}

resource "aws_vpc" "infra" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_internet_gateway" "infra-igw" {
  vpc_id = "${aws_vpc.infra.id}"
}

resource "aws_subnet" "infra-public" {
  count                   = "${var.infra_count}"
  vpc_id                  = "${aws_vpc.infra.id}"
  availability_zone       = "us-west-2a"
  cidr_block              = "10.0.${count.index+1}.0/24"
  map_public_ip_on_launch = true
  depends_on              = ["aws_internet_gateway.infra-igw"]
}

resource "aws_launch_configuration" "foo" {
  image_id      = "ami-03de3c63"
  instance_type = "t2.nano"
}

resource "aws_autoscaling_group" "foo" {
  vpc_zone_identifier  = ["${aws_subnet.infra-public.*.id}"]
  launch_configuration = "${aws_launch_configuration.foo.id}"
  min_size             = 0
  max_size             = 0  # Change me from 0 -> 1 after first apply
}

Steps

Apply config as-is w/ plain terraform apply
Change aws_autoscaling_group.foo.max_size from 0 to 1
Generate a planfile terraform plan -out maxsize.tfplan
Apply the planfile terraform apply maxsize.tfplan

Expected behavior:

Plan is executed as displayed:

~ aws_autoscaling_group.foo
    max_size: "0" => "1"


Plan: 0 to add, 1 to change, 0 to destroy.

Observed behavior:

Error applying plan:

1 error(s) occurred:

* Error reading aws_subnet.infra-public count: strconv.ParseInt: parsing "${var.infra_count}": invalid syntax

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.

Terraform version

Current master: b831ba3

phinze · 2016-02-23T21:55:53Z

Tighter repro w/ template_file:

variable "c" { default = 1 }
resource "template_file" "parent" {
  count = "${var.c}"
  template = "Hi"
}
resource "template_file" "child" {
  template = "${join(",", template_file.parent.*.rendered)} ok"
}

terraform apply # creates resources
# modify template_file.child.template to toggle add/remove extra "ok" string
terraform plan -out template.tfplan
terraform apply template.tfplan
# ...
* Error reading template_file.parent count: strconv.ParseInt: parsing "${var.c}": invalid syntax

scalp42 · 2016-02-23T22:15:02Z

@phinze thanks a lot for looking into it 🙇

pmoust · 2016-02-23T22:16:45Z

Yeap, this breaks our TF-managed infra when using HEAD.

A member of my team reported this happening with interpolation functions + variables in 0.6.9 as well, this happens when a var is referenced from a resource to another >1 levels deep. will try and get a small repro case from him

/cc @alexsapran

phinze · 2016-02-23T22:36:32Z

git bisected introducing commit as #5026

Root cause of OP's issue is uninterpolated var making it to here, but only when using a plan file.

Either there's a mistake in #5026 or it uncovered a latent dependency here on a side-effect of interpolation elsewhere. Either way, will get this sorted out before release!

Gary-Armstrong · 2016-02-24T01:32:42Z

I just wanted to throw in my error which is essentially the same, although mine is not reliably reproducible. This will happen seemingly randomly, but will succeed (or produce same error on a different count var) immediately on the next apply.

* strconv.ParseInt: parsing "${var.head_count}": invalid syntax

scalp42 · 2016-02-24T18:48:24Z

Going to try master, thanks a lot for looking into it @mitchellh @phinze

Related to #5254 If the count of a resource is interpolated (i.e. `${var.c}`), then it must be interpolated before any splat variable using that resource can be used (i.e. `type.name.*.attr`). The original fix for #5254 is to always ensure that this is the case. While working on a new apply builder based on the diff in `f-apply-builder`, this truth no longer always holds. Rather than always include such a resource, I believe the correct behavior instead is to use the state as a source of truth during `walkApply` operations. This change specifically is scoped to `walkApply` operation interpolations since we know the state of any multi-variable should be available. The behavior is less clear for other operations so I left the logic unchanged from prior versions.

davedash · 2017-12-02T00:44:33Z

I'm running into a similar issue today, not sure if I need to create a new ticket.

* module.prod.module.esw_instance.output.deps: Error reading aws_route53_record.external count: strconv.ParseInt: parsing "${aws_instance.instance.count}": invalid syntax

Previously the count value was ${var.enabled?1:0}. This is only a problem when I build a module that depends on the module named prod.

I'm posting first to see if anybody still has similar issues and if this is new, I can try to provide more detail. I'm just not sure what's helpful.

ghost · 2020-04-05T02:38:32Z

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.

phinze added bug core labels Feb 22, 2016

mitchellh mentioned this issue Feb 24, 2016

terraform: don't prune resource if count has interpolations #5302

Merged

jen20 closed this as completed in #5302 Feb 24, 2016

phinze added a commit that referenced this issue Mar 8, 2016

core: Clean up test for issue #5254

5d9637a

mitchellh mentioned this issue Oct 14, 2016

terraform: multi-var interpolation should use state for count #9361

Merged

ghost locked and limited conversation to collaborators Apr 5, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

strconv.ParseInt invalid syntax #5254

strconv.ParseInt invalid syntax #5254

scalp42 commented Feb 22, 2016

phinze commented Feb 23, 2016

scalp42 commented Feb 23, 2016

phinze commented Feb 23, 2016

phinze commented Feb 23, 2016

phinze commented Feb 23, 2016

scalp42 commented Feb 23, 2016

pmoust commented Feb 23, 2016

phinze commented Feb 23, 2016

Gary-Armstrong commented Feb 24, 2016

scalp42 commented Feb 24, 2016

davedash commented Dec 2, 2017

ghost commented Apr 5, 2020

strconv.ParseInt invalid syntax #5254

strconv.ParseInt invalid syntax #5254

Comments

scalp42 commented Feb 22, 2016

phinze commented Feb 23, 2016

scalp42 commented Feb 23, 2016

phinze commented Feb 23, 2016

phinze commented Feb 23, 2016

Config

Steps

Expected behavior:

Observed behavior:

Terraform version

phinze commented Feb 23, 2016

scalp42 commented Feb 23, 2016

pmoust commented Feb 23, 2016

phinze commented Feb 23, 2016

Gary-Armstrong commented Feb 24, 2016

scalp42 commented Feb 24, 2016

davedash commented Dec 2, 2017

ghost commented Apr 5, 2020