-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Destroy fails for "cannot parse as integer" #17793
Comments
Hi @acdifran, Thanks for reporting this. I have a hunch that this is an issue around the separate plan, which isn't often used in conjunction with a full destroy. Could you verify if this works work when using |
Hi @jbardin Thanks for looking into this. I just confirmed that I do NOT have this issue when using the destroy command directly. It seems to be related to the plan command only. |
Hi @acdifran, I haven't yet managed to create a minimal config that can replicate this issue. |
Hi @jbardin Here are the outputs of the vpc module and the outputs of the vpc template: output "vpc_id" {
value = "${aws_vpc.vpc.id}"
}
output "vpce_id" {
value = "${aws_vpc_endpoint.s3.id}"
}
output "vpc_igw" {
value = "${aws_internet_gateway.igw.id}"
}
output "public_subnet_ids" {
value = [ "${aws_subnet.public.*.id}" ]
}
output "private_subnet_ids" {
value = [ "${aws_subnet.private.*.id}" ]
}
output "private_egress_subnet_ids" {
value = [ "${aws_subnet.private_egress.*.id}" ]
}
output "route_tables_public" {
value = "${aws_route_table.public.*.id}"
}
output "route_tables_private" {
value = "${aws_route_table.private.*.id}"
}
output "route_tables_private_egress" {
value = "${aws_route_table.private_egress.*.id}"
} output "vpc_id" {
value = "${module.vpc.vpc_id}"
}
output "vpce_id" {
value = "${module.vpc.vpce_id}"
}
output "vpc_cidr" {
value = "${var.vpc_cidr}"
}
output "public_subnet_ids" {
value = [ "${module.vpc.public_subnet_ids}" ]
}
output "private_subnet_ids" {
value = [ "${module.vpc.private_subnet_ids}" ]
}
output "private_egress_subnet_ids" {
value = [ "${module.vpc.private_egress_subnet_ids}" ]
}
output "route_tables_public" {
value = "${module.vpc.route_tables_public}"
}
output "route_tables_private" {
value = "${module.vpc.route_tables_private}"
}
output "route_tables_private_egress" {
value = "${module.vpc.route_tables_private_egress}"
} |
Thanks @acdifran, that's what I needed. This is triggered when an output referring to a list of resources using the splat ( If you still want to use the separate plan/apply steps, you can work around the issue by setting The minimal case here is
resulting in: |
This is a small fix for hashicorp/terraform#17793. There is no need to rebuild the providers.
I've run into this problem on 0.11.7 but under slightly different conditions.
|
I'm hitting this on 0.11.7 as well. I'm running into many places where I have ternary controls in the counts, or usage through locals. This most affects me when I do partial destroys of the plan -- the delete succeeds, then I go to plan or apply after to recreate those destroyed items and I run into that message a lot. I have no outputs - and I also have no modules or depth to the plan -- it's all flat. |
I also run into this problem on 11.8 when applying a plan which has had portions tainted. |
I see this issue still in 0.11.11. |
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. |
Terraform Version
Terraform Configuration Files
Debug Output
https://gist.github.com/acdifran/0bc2bdfde113b7be39d7e945c12c7f67
Crash Output
Expected Behavior
Plan with the -destroy should destroy all the resources that were created with that same plan.
Actual Behavior
Plan with the -destroy option complains about not being able to parse certain variables:
Steps to Reproduce
Additional Context
I was not having this issue until upgrading to 0.11.6 today. I upgraded to that version to fix this issue: #17425, but that seems to have caused this new one. I've confirmed I don't have this issue on 0.11.0
References
The text was updated successfully, but these errors were encountered: