Closed dhoppe closed 1 year ago
@antonbabenko To be honest, I am pretty confused too. The problem only occurred with one of two modules.
Possibly the problem is caused by Terragrunt, although both modules get the AMI ID via a data source.
In any case, this was the only way to get rid of the error message. It feels wrong, but it does not hurt either. ;)
The problem with using nonsensitive()
in places where it should not be used can lead to errors like "Invalid value for "value" parameter: the given value is not sensitive, so this call is redundant."
More info - https://github.com/hashicorp/terraform/issues/31646
I'd rather find a better solution to the problem than wrap it like you do in this PR.
@antonbabenko I just passed the input values to a .auto.tfvars
and used terraform plan
to make sure that this issue is not caused by Terragrunt, but I get the same error message.
dhoppe at macbook-pro in terraform-aws-ec2-instance on ξ master [?] via π default took 8s
β― terraform plan
...
Plan: 0 to add, 3 to change, 0 to destroy.
Changes to Outputs:
~ instance_state = "running" -> "stopped"
~ tags_all = {
- Contact = "Dennis Hoppe"
- Environment = "dev"
- Owner = "SICO"
- Project = "Atlassian"
# (13 unchanged attributes hidden)
}
β·
β Error: Output refers to sensitive values
β
β on outputs.tf line 146:
β 146: output "ami" {
β
β To reduce the risk of accidentally exporting sensitive data that was intended to be only internal, Terraform
β requires that any root module output containing sensitive data be explicitly marked as sensitive, to confirm your
β intent.
β
β If you do intend to export this data, annotate the output value as sensitive by adding the following argument:
β sensitive = true
β΅
Releasing state lock. This may take a few moments...
The changes can be ignored because the EC2 instance was stopped by a lambda function.
I also can confirm that the input value of the AMI is not sensitive.
dhoppe at macbook-pro in dev/eu-west-1/aws-data on ξ main [?] took 4s
β― terragrunt output -json | jq .aws_ami_tfs4jira_dev_image_id
{
"sensitive": false,
"type": "string",
"value": "ami-010c18a20eec1a70a"
}
By the way, this error only occurs if I set ignore_ami_changes
to true
as I already mentioned at https://github.com/terraform-aws-modules/terraform-aws-ec2-instance/pull/331#issuecomment-1540301986.
I've tried to reproduce the issue and made #340 but it just works as expected.
Could you please try to run the example and see if you can provide me with the failing example?
I use this Terraform module for two different use cases and in a total of three environments.
However, for some reason, only one of two use cases and two of three environments were affected.
So I did some investigation and there seems to be a correlation with the migration from resource "aws_instance" "this"
to resource "aws_instance" "ignore_ami"
. Because after I deleted the resource from the statefile and imported it again, the problem disappeared.
@antonbabenko Sorry for wasting your time.
Glad to hear that the problem is resolved! Also, now we have an example (aka test case) as code :)
I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Description
Using the latest version of this Terraform module and the AWS provider causes the following error message.
Motivation and Context
I would like to be able to use this Terraform module again without causing any error messages. Since the AMI ID is not sensitive anyway, this change should not be a problem.
Breaking Changes
This change does not break backwards compatibility with the current major version.
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request