When using count parameter w/ a split in aws_security_group_rule, receive parsing error "strconv.ParseInt" .. " invalid syntax" #3888
Comments
|
Also: Managed to get the "${length(split(",",var.ids))}" printed to string. The value was 4 (as expected). |
|
Hi @timothykimball. I'm trying to reproduce this on the Running It's possible that this was fixed between v0.6.5 and now though, since the parser has been replaced on |
|
I am also having this issue and my configs which are similar to @jen20's do work. For myself. I've been able to reproduce the issue by passing in values via interpolation in a module. Assuming a module which looks like: This works: This does not work: With the error message: Version: |
|
I seem to hit a similar parse error on occasion. However, I'm not having as much luck reproducing it: The relevant config: The fact that the strconv error shows the variable name as opposed to its value seems to indicate that it wasn't interpolated properly. This comes from: I've seen this on 0.6.6, 0.6.7 and 0.6.8. |
|
I too ran into this same issue. I am trying to use null_resource to apply some file and remote-exec provisioners to a set of resources defined in another module as a way to reuse certain scripts across different resources. I was using code copied from here, except replacing references to I did some troubleshooting, however, and I was able to find a workaround and a probable cause. As a workaround, I passed a second input variable for the count in addition to the joined list, and in the referencing module, I specified a constant value for the variable. Why would this work and not other interpolated strings? It seems that it is interpolating the string either way, but in the former case, the value at that point in time is not a valid integer. That is because the value of count must be known ahead of time, but the value of the variable that I would suggest two improvements to address this issue:
|
|
Outputting the values which strconv.ParseInt has issue with would definitely help me. I'm having a basic version of this issue in an inconsistent manner, and multiple runs are only very slowly revealing bits of the pattern. Just for the record, I'm seeing what is documented in #1373 but not every time! Since I don't know what the exact value is, nor whether it is cast as str or int (does Go do this?), getting to the root is very difficult. Even better, the trace to logfile just stops on this error and nothing is recorded. Not even the strconv.ParseInt error. Summary info for my case [v0.6.8]: Plan it. Multiple CLI execs are run as fast as I can recall the command: |
|
We get this as well, even with today's master. Maybe 20% of the plans produce this error. Almost always with |
|
I'm getting this error as well. It seems to have something to do with how the delimited list is generated. I can get this to work as an output variable, but not in a module or resource input. Below is some information about the error: Error messageVariable outputHow the variable is generated from the public_subnets moduleoutput "subnets" { value = "${join(",", aws_subnet.public.*.cidr_block)}" }Then I pass it into my nat modulemodule "nat" {
source = "./nat"
name = "${var.name}-nat"
vpc_id = "${module.vpc_tools.vpc_id}"
public_subnets = "${module.admin_public_subnet.subnets}"
subnet_ids = "${module.admin_public_subnet.subnet_ids}"
}The resource in the nat modulevariable "public_subnets" { }
resource "aws_eip" "nat" {
count = "${length(split(",", var.public_subnets))}"
vpc = true
lifecycle {
create_before_destroy = true
}
}When I pass the same CIDR list as a literal, the error disappearsmodule "nat" {
source = "./nat"
name = "${var.name}-nat"
vpc_id = "${module.vpc_tools.vpc_id}"
public_subnets = "10.12.16.0/24,10.12.17.0/24,10.12.18.0/24"
subnet_ids = "${module.admin_public_subnet.subnet_ids}"
} |
|
So as I tried to explain in my previous comment, it has less to do with how complicated the interpolated string is, and more to do with whether or not its value can be computed at planning time.
That is why supplying a literal works fine. In that case, the value is not dependent on any resources having been created, so Terraform can compute the value ahead of time. The error message "invalid syntax" is terribly misleading. It should at least say "value cannot be computed at this time" or something to that effect. |
|
That makes sense @deftflux . What still isn't making sense to me is why it's inconsistent. I will say that this happens much more often when running |
|
I am having the exact same issue as colout. It is also inconsistent, I have one VPC deployment where it works, but the same module placed into another VPC deployment throws this error. In my use case I am defining var.public_subnets manually as "10.0.2.0/24,10.0.2.0/24". Works fine in one place, but not the other, using the same input method |
|
@deftflux, what you said makes sense since the issue happens on simple interpolations as well as more complicated ones, but maybe you can help me understand the a few things I found in my testing:
admin_public_subnet's output.tfoutput "subnets" { value = "10.12.16.0/24" }
from my root tf filemodule "nat" {
source = "./nat"
name = "${var.name}-nat"
vpc_id = "${module.vpc_tools.vpc_id}"
public_subnets = "10.12.16.0/24"
subnet_ids = "${module.admin_public_subnet.subnet_ids}"
}Maybe someone who has reproduced this in a simpler environment can confirm this, but things only seem to break for me when I pass a value (even a literal) from the output of another module. Is anyone seeing this who doesn't pass the variable via |
|
I am getting it passed through as a either a literal, or a top scope variable being passed into my module and yield the same result. This worked fine (and still works!) in one VPC built previously with it, but it is now failing with another UPDATE: After doing a bit more digging and using a git bisect to track this down, I found that I was looking in the wrong place; I use the exact line of code shown in the error message, however, I also used a splat to try and derive a count somewhere else in my code. changing this resolved the error, so I now concur with the above statements, that this is to do with interpolation of computed resources and not literals. |
|
I'm curious, does using the Again, I'm not computing the values in a resource. I'm outputting the value as a literal from a module then passing that to a second module where they are interpolated in This fails└── module "parent"
├── module "admin_public_subnet" { ... }
│ └─ output "subnets" { value = "10.12.16.0/24,10.12.17.0/24" }
│
└── module "nat" { public_subnets = "${module.admin_public_subnet.subnets}" ... }
└─ count = "${length(split(",", var.public_subnets))}"This works└── module "parent"
└── module "nat" { public_subnets = "10.12.16.0/24,10.12.17.0/24" ... }
└─ count = "${length(split(",", var.public_subnets))}" |
|
Example of code causing this same issue: https://github.com/chad-upton/Terraform/blob/master/plans/example/vpc.tf#L15 |
|
I am still experience the same issue as noted here #3884 (comment) with source code to reproduce the issue on 0.6.11 |
|
same issue for me, subnets output from one module, input into another. all the |
|
Same for me. Nothing new to add to the discussion as my situation is covered already in this thread. |
|
Im using |
|
All, I found a thread that addresses the counting issue, and it appears a fix is in the works. From #4169: The proposed solution in the linked thread is to create a new class of resource that is evaluated early ("First-class Data Sources"), and can be counted. It looks like a lot of work has already been done, and there are already a few pull requests out there. I'd suggest reading through that thread and giving it a +1 if you like the solution. |
|
just tried v0.7.0 (which is great!) using the new data source resource in place of terraform_remote_state and this bug still seems to exist. Where var.aws_customer_gateways is an output from data source of type "terraform_remote_state" This works, and the tag is populated fine: This still throws a strconv.ParseInt invalid syntax error on the count attribute: |
|
Yes, same with |
|
Also having the same problem when passing a variable into a module the following doesn't work resource "aws_route" "peer_a" { the following works: resource "aws_route" "peer_a" { Using Terraform v0.7.0 |
|
+1 : This is seriously annoying, I can use an element interpolation for the same variable, but count doesn't work. Getting the same ParseInt error |
|
Same issue here in Terraform 0.7.2. I wanted to take advantage of the new aws_availability_zones data source so I didn't have to specify the number of AZs manually, but due to this bug, it doesn't help much, as the following syntax does not work: count = ${length(data.aws_availability_zones.available.names)} |
|
Is it possible to force an order of operations option? If I make a module that has my main infrastructure items and I need it to generate it along with its subnets and gatweays before I build instances then my being able to have my VPC module build first along would resolve most issues with nodes missing the ability to find their resource. Then the data from the output for modules that were forced to generate first could be made available to the VMs. |
|
@mitchellh Thanks for providing an insider look on how difficult this issue is. I have noted that debugging the computation of Could you give any advice on how to continue digging to achieve a fix for this issue? We have been looking to work on a fix for it and would like to hear from an insider to ease the process. |
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
|
Hey @mitchellh! We have achieved a solution for |
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
|
Pretty sure this is also a dupe of #1497 |
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This disables the computed value check for `count` during the validation pass. This enables partial support for #3888 or #1497: as long as the value is non-computed during the plan, complex values will work in counts. **Notably, this allows data source values to be present in counts!** The "count" value can be disabled during validation safely because we can treat it as if any field that uses `count.index` is computed for validation. We then validate a single instance (as if `count = 1`) just to make sure all required fields are set.
|
Thank you @mitchellh! |
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
This commit enables the use computed values when interpolating the count special variable. This is achieved by defering the expansion of `count` during walkInput and walkValidate as the real value isn't necessary at this point. The value will be resolved during walkRefresh and DynamicExpand will work as expected. Partially fixes hashicorp#3888.
|
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. |
ghost
locked and limited conversation to collaborators
and others
This is using terraform v0.6.5
The following module is used:
and when I run in conjunction with the wider project:
If I rewrite
as
it works...
The text was updated successfully, but these errors were encountered: