-
Notifications
You must be signed in to change notification settings - Fork 379
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
Metadata attribute does not act as a computed attribute #1093
Comments
Hello, thank you for opening this issue @krlydm. Based on the trace provided it seems like this is more of a aws provider issue rather than a k8s issue. I would open this in the aws repo instead. |
@BBBmau This is not an AWS provider issue, because you can reproduce with any other resource as I mentioned. Here is an example:
Output of first apply:
Adding a set parameter:
Output of the second apply:
Do you think this is an issue with both AWS and local file resources? |
There seems to be something very odd happening within the metadata block. When running "metadata": [
{
"app_version": "1.16.0",
"chart": "hello-world",
"name": "example",
"namespace": "default",
"revision": 1,
"values": "null",
"version": "0.1.0"
}
], I'll be opening this issue and investigating it a bit further. This should be the main reason why the |
Terraform, Provider, Kubernetes and Helm Versions
Affected Resource(s)
Terraform Configuration Files
Steps to Reproduce
helm_release
and store its metadata attribute somewhere. Runterraform apply
.helm_release
to include aset
attribute.terraform apply
and it will throw anError: Provider produced inconsistent final plan
error.Expected Behavior
metadata
attribute should be treated as a computed attribute after modifying ahelm_release
. Doing some debugging in the current implementation, I think the problem is that themetadata
output piped as input to a resource is not showing as(known after apply)
as shown during the first apply. This is a false assumption, because we should only know these values after the modification is completed on the resource.Based on the documentation,
metadata
is block status of the deployed release, so values will be known after apply only, at least that's what I expect.Actual Behavior
Output from first apply:
Output from second apply (modified with adding a new set parameter):
Error says it is related to
aws_ssm_parameter
, however is independent form the resource you use to input metadata attribute, because I was able to reproduce the same error with other providers and resources as well.Community Note
The text was updated successfully, but these errors were encountered: