Open leynebe opened 3 years ago
Using
"${base64encode(aws_ssm_parameter.tmp.value)}"
instead of"${base64encode(aws_ssm_parameter.tmp.version)}"
does work, but I explicitly do not want sensitive values in the environment variables, which is why I'm using version.
Currently there could be a workaround using the triggers
block, where it should be good to use the .value
of ssm parameter (since/if this parameter value is managed by terraform). Also, it could be a good idea to use the hash of the value.
But the issue is still actual for current aws provider versions, and I think it is a bug (maybe in terraform itself?).
This line sounds strange for me - https://github.com/hashicorp/terraform-provider-aws/blob/b524557/internal/service/ecs/service.go#L700
But using this workaround with the triggers block I receive "Error: Provider produced inconsistent final plan"
As someone who is familiar with Terraform's design but not so familiar with SSM, the way I'm interpreting this issue is that updating the value of an SSM Parameter causes other attributes of that object (versions
here, but maybe also others?) to be implicitly updated as a side-effect, but the provider isn't accurately modeling that behavior and so Terraform can't react to it when planning other resource instances downstream.
However, I do see some logic in the current provider code that seems like it should model this behavior correctly:
Specifically the one that works with names.AttrVersion
seems to be expressing the rule "if value
has changed then version
's value will be decided during the apply phase". That should cause the downstream resource shown in the original example to propose the following change during the first plan:
value = "MQ==" -> (known after apply)
The logic I linked to seems to have been introduced in https://github.com/hashicorp/terraform-provider-aws/pull/22522, whose effect was released in v3.72.0, and so that's a later release than the one that was current when this issue was opened. Therefore it seems like that PR has fixed this issue but this issue remained open because it was later duplicated by https://github.com/hashicorp/terraform-provider-aws/issues/12213.
Community Note
Terraform CLI and Terraform AWS Provider Version
$ tf --version Terraform v1.0.4 on linux_amd64
Affected Resource(s)
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
Debug Output
/
Panic Output
/
Expected Behavior
When the
aws_ssm_parameter
is changed, terraform expects a change. Since there is a reference of theaws_ssm_parameter
version
inaws_ecs_task_definition
I would expect the first apply to contain a recreation of theaws_ecs_task_definition
(and a change to theaws_ecs_service
) resulting in a redeployment of the underlying web service task.Actual Behavior
The first plan/apply lists changes to the
aws_ssm_parameter
:It is only in the second plan/apply that terraform sees changes in the
aws_ecs_task_definition
:Steps to Reproduce
terraform apply
aws_ssm_parameter
value.terraform apply
terraform apply
Important Factoids
/
References
/
Note
Adding the following dependency code to the
aws_ecs_task_definition
also does nothing.Using
"${base64encode(aws_ssm_parameter.tmp.value)}"
instead of"${base64encode(aws_ssm_parameter.tmp.version)}"
does work, but I explicitly do not want sensitive values in the environment variables, which is why I'm using version. Is there any way I can force Terraform to see theversion
change to be as important as thevalue
change?