I noticed there’s a 0.14 version so I thought I’d upgrade. As there’s no info on what one has to do in order to upgrade, I just replaced the old exe with the new one and ran terraform init. I got this answer:
Error: Invalid legacy provider address
This configuration or its associated state refers to the unqualified provider "aws".
You must complete the Terraform 0.13 upgrade process before upgrading to later versions.
What is an unqualified provider??? How is a qualified provider looking like? And where does the qualified go? All Terraform examples I can see use “aws”, no qualifiers whatsoever…
What version of the terraform binary did you upgrade from? Based on the error, it appears that you were using something pre-0.13.x. Based on reading, you must upgrade to 0.13.x (using terraform 0.13upgrade and following along with these instructions). Terraform only supports upgrades from one major feature upgrade at a time.
Once you’ve upgraded your state, it should take to 0.14.x without any forced upgrade process (see here for more details).
I never noticed the need to run those upgrade commands as they are mentioned somewhere in the middle of the X pages deep upgrade notes
Indeed my source was somewhere 0.11 and the binary was 0.12 so I had to do quite some editing until I get to 14. I didn’t need the replace-provider command, the upgrades took care if it apparently.
Thank you all!
For anyone else who finds this wondering about a similar thing, I just wanted to add some extra context:
If you follow what the error message says here and try using Terraform 0.13 first then terraform init in that version should tell you what to do next, if any special actions are required. While I do recommend reading the upgrade guides, for this particular problem Terraform should lead you through the steps as you go, it just takes more than one step because the relevant upgrade tool is no longer included in Terraform v0.14.
This is a very good point and I’m ashamed I didn’t think of it. Now I’m on 0.14 and I didn’t do anything looking like an “update” to me except a terraform init. The docs tell you “the update tool is not part anymore” BUT DO NOT TELL WHERE THE HECK the update tool is
Sooo, what else do I need to do to really update to 0.14? I must say that I didn’t really read all the screens of text the init might have written - I never expected upgrade guides as output from a tool, and as long it said “successful” I didn’t bother.
Error: Failed to decode current backend config
The backend configuration created by the most recent run of "terraform init"
could not be decoded: unsupported attribute "lock_table". The configuration
may have been initialized by an earlier version that used an incompatible
configuration structure. Run "terraform init -reconfigure" to force
re-initialization of the backend.
(just attaching for completeness)
If so, then I must add that it works only if you have “.terrraform” folder, which was initialized by a previous version. If you don’t (and your state is kept remotely, like in s3 f,e.), then “terraform init” with 0.13 does not see the problem, but plan fails (at least for me) with “Error: Provider configuration not present”, while 0.14 gives error on init, same as in original post.
The message you’ve included there seems to be about a backend rather than a provider, so it seems like something quite different than what we’ve been discussing so far in this topic. It seems from what you’ve said here that you found a path forward, but if not then I’d be happy to split this off into a separate topic so we can figure out what’s going on with your backend configuration.
Successfully running terraform apply with Terraform v0.13 ought to have fixed these legacy addresses in the state, but if it did not for some reason then a backup plan is to manually ask Terraform to make the change that Terraform v0.13 should’ve made automatically, like this:
terraform state replace-provider "registry.terraform.io/-/aws" "hashicorp/aws"
This special address with the - instead of the namespace is what Terraform uses to represent a provider address that hasn’t been upgraded to the qualified form yet, so the above explicitly asks Terraform to replace all of the unqualified “aws” addresses in the state with hashicorp/aws, which is a shorthand for registry.terraform.io/hashicorp/aws.
The above command deals with the state. The v0.13 upgrade process also included a command terraform 013upgrade to help with the corresponding configuration changes, although for the AWS provider in particular, because it belongs to the hashicorp namespace now, the configuration changes are not strictly required. (Some other providers now belong to other namespaces and so they require explicit provider requirements.
Our issue was that we were using the wrong workspace. For some reason it was defaulting to an old remote state. I think this is not an issue with terraform itself; it is an issue on how we use workspaces.
Ahh yes, that is a good point worth being explicit about: because each workspace has its own state, if you are using multiple workspace then my note about running terraform apply with v0.13 before upgrading to v0.14 applies to each workspace separately, because all of them will probably contain unqualified provider references that need to be updated to match the source addresses in the configuration.
The variant of that if you want to use terraform state replace-provider instead of terraform apply would be to switch to each workspace in turn to run that command. The terraform state commands operate on the state for the current workspace, so you can make that switch in all the same ways as you would to select a workspace for terraform apply.
Would it be so wrong if Terraform asked to do those upgrades by itself, at the next run? And if like me it was upgraded from 12 to 14, if it did both upgrades in one run and by itself? What’s the point of forcing the user going through the command line and documentation hoops?
When you run Terraform it should do so. The idea is that it runs the 0.13 upgrade, but you can run the terraform 0.13upgrade command if it doesn’t for some reason. And if that doesn’t fully work you can use the terraform state replace-provider.
If you are trying to upgrade straight from 0.12 to 0.14 that isn’t supported and wouldn’t “just work”. Upgrades are only supported between a single minor version (e.g. 0.12 to 0.13), so you need to first switch from 0.12 to 0.13 and only then move from 0.13 to 0.14.
Alternatively if you want to jump directly none of the automated upgrades will work (as it should handle 0.13 to 0.14 automatically but wouldn’t handle states still in 0.12 format) and you’d have to do things more manually.
If 12->13 works seamless and 13->14 works seamless, I would assume 12->14 would work just as seamless… there are exactly the same steps, in the end. Anyway, it is how it is and I assume me complaining in a forum won’t change the plan.
It wouldn’t even be a problem if the program output and/or the upgrade documentation would have said exactly this, in a couple of words:
check your version
download the next version and run terraform apply
repeat until you reach the desired version.
if errors, here’s the complete upgrade guide.
But all I saw was the 3000+ words extensive guide and I just TL;DR.
The 0.13upgrade command is only available in version 0.13 (not 0.14) which I presume is a combination of not wanting to have to support/test every combination of upgrades forever and the fact that they only advertise supporting upgrades from one minor version to the next.
Maybe it does need to be clearer for those upgrading
@rigogsilva Thanks a ton, we had the same exact issue. Upgrading from 0.13 -> 0.14 getting " Error: Invalid legacy provider address". The issue was we were operating on the wrong workspace.
We encountered a similar problem in our operational environments today. We successfully completed the terraform 0.13upgrade command. This indeed introduced a versions.tf file.
However, performing a terraform init with this setup was still not possible, and the following error popped up:
Error: Invalid legacy provider address
Further investigation in the state file revealed that, for some resources, the provider block was not updated. We hence had to run the following command to finalize the upgrade process.
terraform state replace-provider "registry.terraform.io/-/google" "hashicorp/google"
EDIT Deployment to the next environment revealed that this was caused by conditional resources. To easily enable/disable some resources we leverage the count attribute and use either 0 or 1. For the resources with count = 0, that were unaltered with Terraform 0.13, the provider was not updated.
When i run the command with version 0.13.5 $ ./run.sh 0.13upgrade
I get the error
Failed to load state: state snapshot was created by Terraform v0.14.2, which is newer than current v0.13.5; upgrade to Terraform v0.14.2 or greater to work with this state
When i run the following command
$ ./run.sh state replace-provider registry.terraform.io/-/aws hashicorp/aws
I get the error
This configuration or its associated state refers to the unqualified provider
"aws". You must complete the Terraform 0.13 upgrade process before upgrading to later
versions.
Not sure what exactly to do. Feels like i am stuck in a cycle. 0.13.5 won’t allow me to run upgrade because of state file error. 0.14.2 won’t allow me to replace provider as apparently the upgrade command has not been run
My IaC was completely messed up with several version between 0.13.x and 0.14.x (I was using terragrunt, therefore which module were created with one different version).
I’ve Just fixed it using tfswitch (Install - TFSwitch) to easily switch terraform version and the command:
terraform state replace-provider "registry.terraform.io/-/aws" "hashicorp/aws"
To fix the error described in the original post
NOTE: if the module was created in version 0.13.x, switch to this version and run the command above and then switch back to your 0.14.x version and finally run: ```terraform init``. If you try to run the replace-provider command with a 0.14.x version it will not work and you will be tied in a annoying loop!
I hope this breaks some loops that were described here.
