Open tschneider-aneo opened 3 months ago
I was redirected here by @liamcervante after posting the following issue on the Terraform repo : https://github.com/hashicorp/terraform/issues/35332
The reason why I did not reference the kubernetes secret resource directly is because I encountered this bug while trying to access a kube secret created by a Helm release resource (deployed with TF). But deploying a Helm release is quite tedious and not necessary to reproduce the bug.
This does look like an issue with the way binary_data
's UX was designed. Because it requires users to set both a key and a value for the Secret's attributes that it requires encoding of, Terraform treats these as "known values" at plan time and doesn't accept the new (encoded) value that the datasource tries to insert there during apply.
We will look further into this, but the fix is likely to require schema changes which we only allow on major version releases and thus will be while out.
In the mean time, my suggested workaround is to use Terraform's own base64encode function on the values of the data
attribute. This should similarly yield base64 encoded values, but avoid the strange UX of setting a dummy value like binary_data
requires.
Terraform Version, Provider Version and Kubernetes Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/tschneider-aneo/691a2d49d4ee0a69ec035b00622834a9
Panic Output
Steps to Reproduce
terraform init
terraform apply
Expected Behavior
What should have happened? TF should know that the local file's content will be known during apply and should just wait for the data source to retrieve the kube secret data.
Actual Behavior
What actually happened? TF seems to be converting an unknown value to a null value, producing the inconsistent final plan error.
Important Factoids
References
Community Note