Terraform upgrade and multiple versions.tf, do child modules inherit the provider versions? - terraform

Question

Not very experienced with Terraform. I upgraded my project from 12 to 13 and looking to upgrade it to 14 afterwards.
As the documentation specifies, I ran terraform 0.13upgrade and terraform 0.13upgrade module, my directory became like this:
terraform
├── module
│ ├── main.tf
│ └── versions.tf
├── main.tf
└── versions.tf
I moved my versions but the problem is that I specified them only in the root versions.tf:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.0"
}
}
in module/versions.tf I kept only:
terraform {
required_providers {
google = {
source = "hashicorp/google"
}
}
Do child modules inherit the version from the root (where they are imported) or does this mean my module will automatically run with a more recent provider version (3.64 I think)?
Should I simply remove module/versions.tf? (It's tiresome to have 2 versions to edit everytime).
Thanks!

Answer 1

For a given Terraform configuration (which includes both the root module and any other modules you might call), there can be only one version of each provider. Terraform recognizes that two providers are "the same" by them having the same source value after normalization, and in your examples here both are using hashicorp/google, which is short for registry.terraform.io/hashicorp/google, and so both of them need to be able to agree on a particular version of that provider to use.
Terraform handles version constraints from multiple providers by combining them together and trying to honor all of them together. In your examples here you've written no version argument in the child module, and this means "any version is allowed".
Terraform will therefore look for an available provider version that matches both the ~> 3.8.0 constraint and the implied "any version" constraint, and since the ~> 3.8.0 constraint is a proper subset of "any version" it effectively takes priority over the open constraint in the child module. This is not strictly "inheritance", but it happens to behave somewhat like it in this case because the child module is totally unconstrained.
A more interesting example would be if both of your modules specified different version constraints, which means we can see a more interesting effect of combining them. Let's pretend that your two modules had the following requirements instead:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.2"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = ">= 3.8.5"
}
}
}
In this situation neither of these constraints is a subset of the other, but they do have some overlap: all of the 3.8.x versions from 3.8.5 onwards are acceptable to both modules. Therefore Terraform will select the newest available version from that set.
If you write two modules that have conflicting version constraints then that would be an error:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.7.0"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.5"
}
}
}
There is no provider version that is both a 3.7.x release and a 3.8.x release at the same time, so no release can ever possibly match both of these constraints, and thus provider version selection will fail. It's for this reason that the Terraform documentation section Best Practices for Provider Versions advises to use ~> version constraints only in the root module.