-
Notifications
You must be signed in to change notification settings - Fork 380
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
Larger diff than expected when updating helm_release 'set' 'value' #916
Larger diff than expected when updating helm_release 'set' 'value' #916
Conversation
Fix issue hashicorp#915 where when re-deploying a helm_release after changing a 'set' 'value' the plan generated indicates that values not changing will be deleted and re-applied even though they have not been changed. The issue is caused by the resource diff process removing the 'set' 'type' value from the state as it was not set in the original terraform code. When initially applying the plan the default value "" was used for the 'set' 'type' and stored in the state, when redeploying the original value of 'set' 'type' is requested but as no default has been set in the schema it is marked as removed, which then results in null being stored in the state for the value of 'set' 'type'. This cause an internal warning to be generated in the logs: "Provider "registry.terraform.io/hashicorp/helm" produced an unexpected new value for helm_release.test during refresh."
@jrhouston - as this is a first PR for terraform helm provider, is there anything more you might need/I've missed in this PR? |
Thanks! do you have kind of your own private registry where you uploaded your custom build of the provider? |
Who should we be requesting a review from to get this merged? seems like a very straightorward PR ... |
@fcrespofastly looking at the contributors and some previous PRs it looks like a key contributor is @jrhouston |
Hey @jrhouston! 👋🏻 👋🏻 this seems like a pretty reasonable and straightforward PR, any chance we can get this merged? We currently can't render manifests which impacts our ability to validate the plan prior to apply. |
Hey @jrhouston any chance you can take a look at this one? |
Dear @jrhouston, @BBBmau I noticed you recently helped merge and release few fixes, can you please spare a minute to get this fix in? this is a straightforward change and addresses both #915 & #711 🙏🏼 |
Hey @jrhouston 👋🏻 👋🏻 ! I noticed you reacted to @dkulchinsky's comment. Did you have a chance to review this PR? 🙏🏻 Thanks in advance!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this @adcharre! 🚀
@jrhouston many thanks for reviewing and getting this merged 🙏🏼 could you also help to get this fix released in a new patch version? |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Description
Fix issue #915 where when re-deploying a helm_release after changing a 'set' 'value' the plan generated indicates that values not changing will be deleted and re-applied even though they have not been changed.
The issue is caused by the resource diff process removing the 'set' 'type' value from the state as it was not set in the original terraform code. When initially applying the plan the default value "" was used for the 'set' 'type' and stored in the state, when redeploying the original value of 'set' 'type' is requested but as no default has been set in the schema it is marked as removed, which then results in null being stored in the state for the value of 'set' 'type'.
This causes an internal warning to be generated in the logs:
"Provider "registry.terraform.io/hashicorp/helm" produced an unexpected new value for helm_release.test during refresh."
Acceptance tests
Release Note
Release note for CHANGELOG:
References
Community Note