Skip to content
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

Error when var.config.*.subnet_route_table_ids derives from a value in the same state #31

Open
korenyoni opened this issue Nov 17, 2022 · 1 comment
Labels
bug 🐛 An issue with the system

Comments

@korenyoni
Copy link
Member

korenyoni commented Nov 17, 2022

Found a bug? Maybe our Slack Community can help.

Slack Community

Describe the Bug

When var.config.*.subnet_route_table_ids is in the same state and has not yet been applied, the following occurs:

module.tgw_attachment.data.aws_ec2_transit_gateway.this[0]: Read complete after 0s [id=tgw-9435ccad528479164]
╷
│ Error: Invalid count argument
│ 
│   on .terraform/modules/tgw_attachment/modules/subnet_route/main.tf line 19, in resource "aws_route" "count":
│   19:   count                  = var.route_keys_enabled ? 0 : length(local.route_config_list)
│ 
│ The "count" value depends on resource attributes that cannot be determined
│ until apply, so Terraform cannot predict how many instances will be
│ created. To work around this, use the -target argument to first apply only
│ the resources that the count depends on.
╵

This also happens when var.route_keys_enabled is true:

module.tgw_attachment.data.aws_ec2_transit_gateway.this[0]: Read complete after 0s [id=tgw-9435ccad528479164]
╷
│ Error: Invalid for_each argument
│ 
│   on .terraform/modules/tgw_attachment/modules/subnet_route/main.tf line 8, in resource "aws_route" "keys":
│    8:   for_each               = var.route_keys_enabled ? local.route_config_map : {}
│     ├────────────────
│     │ local.route_config_map will be known only after apply
│     │ var.route_keys_enabled is true
│ 
│ The "for_each" map includes keys derived from resource attributes that
│ cannot be determined until apply, and so Terraform cannot determine the
│ full set of keys that will identify the instances of this resource.
│ 
│ When working with unknown values in for_each, it's better to define the map
│ keys statically in your configuration and place apply-time results only in
│ the map values.

│ Alternatively, you could use the -target planning option to first apply
│ only the resources that the for_each value depends on, and then apply a
│ second time to fully converge.

Expected Behavior

When var.subnet_route_table_ids derives from a value in the same state, creating a TGW attachment should still be possible.

This is coming from operations in the subnet_route submodule that are too complex on unknown values (namely setproduct()).

route_config_list = local.route_config_provided ? [for i in setproduct(var.route_table_ids, var.destination_cidr_blocks) : i] : []
route_config_map = local.route_config_provided ? { for i in local.route_config_list : format("%v:%v", i[0], i[1]) => i } : {}

Steps to Reproduce

Steps to reproduce the behavior:

  1. Write a module with the VPC and its subnets in the same state as this module.
  2. Pass the subnet route table IDs from 1 to var.subnet_route_table_ids
  3. Run terraform plan

Screenshots

If applicable, add screenshots or logs to help explain your problem.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

  • Module version v0.9.1
  • Terraform v1.3.4

Additional Context

Add any other context about the problem here.

@korenyoni korenyoni added the bug 🐛 An issue with the system label Nov 17, 2022
@zack-is-cool
Copy link

FWIW, this is how their test works
https://github.com/cloudposse/terraform-aws-transit-gateway/blob/main/test/src/examples_complete_test.go#L32-L55

you need to deploy the VPCs first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 An issue with the system
Projects
None yet
Development

No branches or pull requests

2 participants