I understand that terraform plan outputs a tilde (~) when something has changed. Usually there are + (plus) and - (minus) signs for lines which were added or removed.
Then there is the → (arrow) sign to indicate what has changed. But what does it mean when a ~ (tilde) is shown but none of the other symbols?
For example I got this output:
# module.akscontent.module.appinsights.kubernetes_cluster_role_binding.appinsights_k_8_s_property_reader_binding has changed
~ resource "kubernetes_cluster_role_binding" "appinsights_k_8_s_property_reader_binding" {
id = "appinsights-k8s-property-reader-binding"
~ metadata {
name = "appinsights-k8s-property-reader-binding"
# (5 unchanged attributes hidden)
}
# (2 unchanged blocks hidden)
}
Does this mean that the name attribute in metadata has been added? If yes why is there no + (plus) sign in front of that line? If name has been changed why is there no → (arrow) which indicates what the previous value was?
I think what you have found here is a bug of some sort. Based only on what you’ve shared I’d guess that the provider has described a change to Terraform that Terraform itself doesn’t understand how to render, and so the result is confusing.
One way this could happen is if the provider describes a change that incorrectly exposes an implementation detail rather than a true meaningful change. For example, some providers consider null and "" (the empty string) to be exactly equivalent for some arguments, but if the provider then still describes a change between those two values that would not be a sensible change and so Terraform’s UI might be confused by it.
One way to get more information here would be to bypass the UI rendering and inspect the underlying data in JSON format instead:
terraform plan -out=tfplan
terraform show -json tfplan
The JSON representation of a plan will probably be long and dense but if you pretty-print it and load it into a text editor you can hopefully find the entry for this particular resource instance and see its “before” and “after” values directly, without any of the UI diffing heuristics getting in the way, and hopefully you’ll see that there is some kind of difference between the two that the UI didn’t understand how to describe.
If that does end to being the answer then I’d suggest opening an issue in the Kubernetes provider GitHub repository so that the provider maintainers can try to improve this or can report a diff UI bug to the Terraform CLI maintainers if the provider’s behavior turns out to be correct and it’s the CLI diff rendering that’s wrong.