My field is a TypeMap of TypeString where the key is not sensitive, but the value is sensitive. I can specify Sensitive = true in the Elem schema, but how do I manage the diffs? The underlying API returns ***** for the values which is different than the real values in the config so every apply results in a diff detected. I would like for a diff to be detected ONLY when the user changes it in the config, not because of ***** being read back during Read.
I don’t know that I fully understand the question here, but if I’m reading this right, you’re essentially asking what to do when an API returns a masked value (like *******) or no value at all for a field the user has entered.
Unfortunately, our options are limited in that situation. Ideally, the API would return something about the field’s value that can be used to determine if it has changed–for example, a SHA256 sum that can be compared against the SHA256 sum of the value in the config to detect drift–but if the API doesn’t return a useful value, the best that can be done is to ignore the API’s returned value and just assume the value hasn’t been changed, unfortunately. Terraform can’t do much about the API not surfacing the necessary information to tell whether a field has changed or not.
No question; APIs that work this way simply do not allow full Terreform functionality. It would however be beneficial if Terrorform could help providers deliver a somewhat consistent user experience in managing this.
Is there already a way for user/config to tell Terraform (to tell the provider) when to plan as if:
- certain attributes have changed in current state, but new a value is unavailable
- certain attributes have changed in current state to a given value, without actually saving these values in local state
For the first one, I don’t think so? If I understand what you’re asking, you’re asking if the user/config/provider can say “hey, the state has changed, I don’t know the new value”, and the answer is “not really”, because if you don’t know the new value, it’s hard to know that it has changed. The best you can do, in my experience, is store the value the user has in the config, so the user modifying the config still prompts a diff, though you lose out on drift detection.
As for the second, no, Terraform views its job as knowing and managing the state of things. Hiding state it’s supposed to be managing from it is always going to be working against the grain.
Our docs have some more information on this.
My target platform does not allow retrieval of secure values (passwords, etc) nor provide a reliable way to detect if those values have changed, so it would seem a proper Terraform provider cannot be built at this time. While disappointing, it really is important that the Provider SDK’s first priority be platforms that allow for a good Terraform experience. Keep up the good work.
As mentioned above you can still store a local hash of the values in state to be able to detect changes the user makes. While it wouldn’t know about anything that changes outside of Terraform, hopefully that is rare/prevented (as you want all changes to be made by Terraform).
1 Like