init with 1.10 should work without -reconfigure after upgrade from 1.8 or 1.9 #36174
Comments
|
Hi @schollii, Thanks for filing the issue. Yes, that error message isn't great, because it's trying to cover a generic situation for any backend implementation and doesn't know why a particular backend may have changed it's stored data structures. The storage backends are developed independently from the core codebase, although they still need to be bundled into the CLI binary. This poses a bit of a problem with coordinating upgrade cycles, and is something we want to be able to decouple. This is why the state storage backends are not included in v1 compatibility guarantees, allowing the backend developers to continue development without being tied forever to the CLI release cycle. The S3 backend is also called out in the upgrade guide as requiring I'm not sure what a resolution here would be at this point, since v1.10 is already released with the change in data structures, going back would take yet another release and another multiple rounds of |
|
I have faced a similar issue in Amazon China. It works well with 1.10.0 but "Backend configuration changed" with 1.10.1. |
|
Thanks for the report @schollii. I do appreciate the feedback and will deliver this to the AWS provider team at HashiCorp, as well as our product management team. Per @jbardin's comment above, there is not anything to be done about this specific reported instance other than relay it as process feedback for the future, so I am going to close this as a bug. Please feel free to let me know if you think there is some other resolution that is possible. |
|
Yes i was thinking that 1.10.2 would not automatically cleanup the backend state, and add an extra option for when this is desired. Then people would know to skip 1.10.0 and 1.10.1 if the -reconfigure required in 1.10.1 is a problem. Tbh I'm guessing that this kind of change is likely to happen again, so a way for you to deprecate something in the backend, and give users time to switch, is likely to be useful more than just this once. |
|
At this point the config structure can't be changed back immediately, because that would force all users who have already upgraded to reconfigure during a patch release, then again during the next point release. I think all we can do right now is try to make sure the backend developers are more vocal about pending deprecations. Better deprecation processes alone won't provide a solution here either though, because the change in internal backend structure is what forced the reconfiguration, not whether you have already upgraded your configuration to remove deprecated attributes. I think it really comes down to having backends extracted from core entirely so that their development and upgrade cycles are not tied together. Aside from the other technical reasons we want that, it would better match user's expectations around version upgrades similar to that of providers. |
|
Linking to #5877 |
Terraform Version
Terraform Configuration Files
Debug Output
Expected Behavior
terraform init should just work with 1.10 after upgrading from 1.8 and 1.9. I'm guessing upgrading to 1.10 from any earlier before 1.8 will have same issue but I did not check.
Actual Behavior
It aborts with a confusing and unsettling error message:
When I saw that at first, I wasn't sure which one I should pick, since obviously I had not changed anything to the backend config that could guide me in choosing the correct action.
After web search I was lucky to find #36150. Turns out
-reconfigureis required, in both directions: pre-1.10 to 1.10, and back from 1.10 to prior version.Since 1.10 is a minor release, I'm reporting the requirement for
-reconfigureas a bug:-reconfigurefrom a machine so that the state in s3 gets updated, then the terraform that runs in ci/cd has to also be upgraded to 1.10 otherwise it will give the same init error (and we can't skip the init -- the plan will fail saying init is required).-reconfigure.From that other issue #36150, this seems to happen because tf is doing some cleanup of state for obsolete args. I am all for cleanups, but terraform 1.10 should not do this automatically as part of a minor release, it should be optional so we can do this as a separate action. If this were a major release, sure. But on a minor release, this SHOULD BE CONSIDERED A BUG. Instead a new command line switch eg, so that we can do this cleanup when we are ready, eg we should be able to wait for the next major release even if that happens in 2 years. Make the cleanup mandatory only for major release (tf 2.0).
Steps to Reproduce
This is already documented in the other ticket, but I'll repeat here:
tfswitch --latest-stable 1.10)Additional Context
No response
References
The text was updated successfully, but these errors were encountered: