-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
for_each not working well when creating aws_route53_record #14447
Comments
WorkaroundHere is another workaround that may be more convenient, as it avoids running apply twice.
|
I think this should be tagged with service/acm instead of service/route53 since the |
From the comment in the tests for aws_acm_certificate_validation, it looks like it might be fixed by the upgrade to SDKv2? Either that, or no one could get it to work... |
@wjam that comment was because the older Terraform Plugin SDK version 1 testing framework only emulated early 0.12 Terraform CLI functionality (and did not receive updates for |
There is a bug in using for_each for the domain_validations_options set (changed from a list in provider ~=3.0) that would require targeted creation of the certificate resources first (see [this issue](hashicorp/terraform-provider-aws#14447)). Using provider version 2.7 (at the time of writing) mitigates this.
I've found similar issues and hopefully this will help with the debugging. Using the following to create the validation records in both cases
If we use pre-defined values for the
However we generate the DNS names as part of the same stack so rather than building FQDNs which is our case becomes quite complex (multiple zones, different domain name formatting options etc) we use the outputs from the Route53 records. This causes the 'attributes that cannot be determined' error from above. This works fine when we were using the previous count method such as in the terraform-aws-acm module
I'll post a workaround if I find one |
There is a bug in using for_each for the domain_validations_options set (changed from a list in provider ~=3.0) that would require targeted creation of the certificate resources first (see [this issue](hashicorp/terraform-provider-aws#14447)). Using provider version 2.7 (at the time of writing) mitigates this. Also terraform 0.12upgrade created version.tf files for all projects. Moving this to a global version_constraints.tf linked in the projects as well.
Dug a bit deeper into this and tried doing some
Fails with
Yet
Succeeds |
In the first one you're iterating over a terraform resource's property that's apparently unknown at plan stage and in the second over a string which is determined. So it seems like terraform bails whenever the iterable's count is unknown or is consists of values unknown at plan stage. Only I don't get why it doesn't follow the same behaviour of implicit dependency tracking to just wait with execution until the unknown is known... Even adding explicit dependency doesn't seem to help. |
I think the above is a bug in Given the Domain Validation Options is a set of 'unknown length' and converting it to a list makes the ordering arbitrary again I think the only way I'm going to get round this one is to reengineer the module to build the domains as inputs to the ACM Cert :( |
Did a little more delving into this and worked out exactly what the problem is here. The slight worry of this is that so long as Also not sure if I'm really contributing to the original issue at this point or this is a separate issue! |
There is a bug in using for_each for the domain_validations_options set (changed from a list in provider ~=3.0) that would require targeted creation of the certificate resources first (see [this issue](hashicorp/terraform-provider-aws#14447)). Using provider version 2.7 (at the time of writing) mitigates this. Also terraform 0.12upgrade created version.tf files for all projects. Moving this to a global version_constraints.tf linked in the projects as well.
Decided that this is a bug that could cause problems, but not really sure how to handle it. If the certificate is to be created only then all is well at the moment. Tried taking a look at the code, failing the diff due to
and changing |
Same here. I actually got this snippet from the provider upgrade for aws and now plan fails everytime. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade Would have at least liked a working snippet that didn't break plans 🤦 |
Is above bug resolved? just curious, if it is resolved which aws provider version we have to upgrade? |
I'm hitting the same problem, using TF 0.13.4 and aws 3.11.0, with this code:
i get this error:
I have migrated a different TF plan from 0.12 to 0.13 with this resource definition (take straight from the docs), but for whatever reason it doesn't work in this plan. Update: I am aware how ugly this is, but at least it doesn't error out:
|
@jangrewe it's funny, that works fine for me. The only real difference I see in my code is that I am not doing a data lookup inside the
|
That was the exact problem I had cause I was depending on the output of the R53 creation which isn't known until it has been created. You need to make sure @jangrewe I assume there is nothing that the data resource is depending on before fetching it's data? I know that mine works in a similar fashion, the main difference is that instead of using the @babuamudala can you share your code snippet? Can you also share which version of the AWS provider you are both using? |
@simonc-613 yes, the data source gets a variable passed into the module, that's all for dependencies. I also noticed that the original method from the docs works fine if the record already exists, that's why i initially didn't get this error when i was doing a migration from 0.12 to 0.13. But when i then tested my module after destroying all resources, the error showed up. PS: ugh, i have no clue why i'm using a |
@simonc-613 referred this https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade#resource-aws_acm_certificate resource "aws_acm_certificate" "cert" { lifecycle { resource "infoblox_record_cname" "www" { lifecycle { resource "aws_acm_certificate_validation" "cert" { |
@simonc-613 My bad, above code totally work fine with aws provider 3.0.0, it is not working with 2.66.0 . For workaround used tolist()func. |
@babuamudala as in it works if I honestly have no idea other, in our stack we create the R53 record which terraform seems to do earlier than creating the cert. I've looked through the code for the diff again and it doesn't do any DNS look ups or anything so I'm beyond confused here. |
What's the status of this? I'm in the same scenario that other are in, I have to target state on bootstrapping. |
Hey @jsipprell, I hit this very same issue today and upgrading to version 3 of the AWS provider fixed my issue. They mention it in the upgrade guide too. I did have to upgrade some other modules I was using first because the modules had provider constraints that meant I only pulled down the version 2.70.0 of the AWS provider even when I did a |
@philipwigg, I'm using version >= 3.36.0 already. |
I also encountered this error in version resource "aws_acm_certificate_validation" "main" {
certificate_arn = aws_acm_certificate.main.arn
validation_record_fqdns = [aws_route53_record.acm_dns_validation.fqdn]
}
resource "aws_acm_certificate" "main" {
domain_name = local.domain_name
validation_method = "DNS"
}
resource "aws_route53_record" "acm_dns_validation" {
allow_overwrite = true
zone_id = data.aws_route53_zone.main.zone_id
name = local.main_acm_domain_validation_option.resource_record_name
type = local.main_acm_domain_validation_option.resource_record_type
records = [local.main_acm_domain_validation_option.resource_record_value]
ttl = 60
}
data "aws_route53_zone" "main" {
name = local.zone_name
private_zone = false
}
locals {
main_acm_domain_validation_option = tolist(aws_acm_certificate.main.domain_validation_options)[0]
domain_name = "${lower(random_string.suffix.result)}.${local.zone_name}"
zone_name = "example.com"
}
resource "random_string" "suffix" {
length = 8
special = false
} The misleading part with this issue is that one need to be sure that the "unknown-until-apply" part, in my case the While the example from the docs do work for domain names known in advance, I think it would make sense to include in the example a dynamically created domain name. |
This is also affecting me. When i use a r53 zone that is created outside of the templates and use a Exact same logic but create a new zone within the template, and pass that ID to the │ Error: Invalid for_each argument
│
│ on aws/modules/certificate-tls-public/main.tf line 46, in resource "aws_route53_record" "cert_validation":
│ 46: for_each = {
│ 47: for dvo in aws_acm_certificate.this.domain_validation_options : dvo.domain_name => {
│ 48: name = dvo.resource_record_name
│ 49: record = dvo.resource_record_value
│ 50: type = dvo.resource_record_type
│ 51: }
│ 52: }
│ ├────────────────
│ │ aws_acm_certificate.this.domain_validation_options is a set of object, known only after apply |
Note sure if this is related but a data source also fails? data "aws_route53_zone" "app" {
for_each = toset(var.zone_ids)
id = each.key
} Error is |
Still running into this issue with AWS provider 5.1.0. I'm using static domain names too, following the Terraform example.
Yields
|
I was starting to look at this issue and was attempting to reproduce the error and am currently unable to using the following config and provider version
Is a second person able to verify that they either can or cannot reproduce this error on the latest provider version? |
I can confirm I'm seeing this issue all of a sudden with aws provider version |
I can confirm I have just started seeing this issue, provider version: 4.58.0 and terraform version 1.4.6. Same provider version and terraform version were working on June 9th. |
@iamgeef I am unable to replicate with the config i posted earlier on that same terraform and provider version. Can you provide me the code you are able to replicate with? |
We encountered the same issue.
|
i'm encountering the same issue, would appreciate a response here. |
The aws_acm_certificate.cert.domain_validation_options.0.resource_record_name works in 2.70.0, but this doesn't work in 3.0.0. Checking the latest 3.0.0 document, now terraform use the for_each expression to iterate the value, but when I use this new approach to create aws_route53_record, I got the following error and can't create resources.
The "for_each" 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 for_each depends on.
For a workaround, I have to run the following commands to finish the creation,
terraform init
terraform plan -target=aws_acm_certificate.cert -out=tfplanout
terraform apply "tfplanout"
terraform plan
terraform apply
The text was updated successfully, but these errors were encountered: