-
Notifications
You must be signed in to change notification settings - Fork 103
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
data.tls_certificate.this.certificates is empty list of object #244
Comments
This is affecting us as well... |
I have faced this bug too. Pinning TLS provider version to 3.4 also helps me. |
I am facing this issue too |
Same here and pinning TLS provider to 3.4 works. |
can anyone explain or provide code for pinning tls provider to 3.4 ? |
terraform { |
Hi folks 👋 Thank you for the report and sorry you are running into this frustrating behavior right now. My team has done some investigation on this and we have some leads on what the underlying issue might be, however it is going to take some additional time to sort out a potential solution. This issue appears to occur only when the data source has an "(known after apply)" (unknown) value for the As an easier fix in your environment, pinning to TLS provider version 3.4.0 using the Terraform configuration recommended in the above comments will ensure your Terraform runs continue as before without the special workaround, e.g. terraform {
required_providers {
tls = {
source = "hashicorp/tls"
version = "3.4.0"
}
}
} We will post an additional update when we have information to report. Thank you for your patience. |
Upstream issue: hashicorp/terraform-provider-tls#244
…f `Object`, instead of a blocks' list This is necessary. so that we can express to Terraform that the attribute is indeed `Computed` and it can't be expected to be populated, until the data source is read. This was creating an issue (see #244), as Terraform protocol doesn't support expressing that a Block is Computed: only attributes can be. This approach avoids the use of `NestedAttributes`, and as such is compatible with Protocol v5 (i.e. TF >= 0.12).
…ead of `Blocks` (#246) * Define `certificates` in `tls_certificate` data source, as a `List` of `Object`, instead of a blocks' list This is necessary. so that we can express to Terraform that the attribute is indeed `Computed` and it can't be expected to be populated, until the data source is read. This was creating an issue (see #244), as Terraform protocol doesn't support expressing that a Block is Computed: only attributes can be. This approach avoids the use of `NestedAttributes`, and as such is compatible with Protocol v5 (i.e. TF >= 0.12). * Preparing CHANGELOG for v4.0.1 * Adding acceptance test for `tls_certificate` data source, exercising a scenario where "computed certificates are unknown until applied" * Apply suggestions from code review Co-authored-by: Brian Flad <[email protected]>
Hi all, and apologies for the inconveniences caused by this issue. Version Any feedback will be very appreciated. |
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. |
Terraform CLI and Provider Versions
terraform
1.2.5hashicorp/tls
4.0.0hashicorp/aws
4.23.0Terraform Configuration
Expected Behavior
terraform plan
should work normallyActual Behavior
terraform plan
fails with the following errorSteps to Reproduce
Add
to your state and run
terraform plan
How much impact is this issue causing?
High
Logs
No response
Additional Information
Works with downgrading
hashicorp/tls
provider version to3.4.0
.This use-case is also shown as an example in https://registry.terraform.io/providers/hashicorp/tls/latest/docs/data-sources/certificate
Code of Conduct
The text was updated successfully, but these errors were encountered: