How to use global terraform block definitions for required providers and versions?

Question

I cloned this AWS - terraform - sample repo in order to play around with a IaC-defined CI/CD - pipeline in terraform.

Yet, when I run the terraform linter tflint I get the following warning in every single "main.tf" of all subdirectories. The following example will be taken from the subfolder modules/iam-role/:

TFLint in src/infrastructure/modules/iam-role/:
2 issue(s) found:

Warning: terraform "required_version" attribute is required (terraform_required_version)

  on  line 0:
   (source code not available)

Reference: https://github.com/terraform-linters/tflint-ruleset-terraform/blob/v0.2.1/docs/rules/terraform_required_version.md

Warning: Missing version constraint for provider "aws" in "required_providers" (terraform_required_providers)

  on main.tf line 130:
 130: resource "aws_accessanalyzer_analyzer" "codepipeline_analyzer" {

Reference: https://github.com/terraform-linters/tflint-ruleset-terraform/blob/v0.2.1

The mentioned reference webpages did not help resolve the issue, but what it did was copy-pasting the following terraform-block into each and every "main.tf":

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.20.1"
    }
  }

  required_version = ">= 1.1.7"
}

I don't understand why such a violation of the DRY-principle is necessary in order to get rid of these linter warnings.

To my mind, it must be possible to define these required providers and versions in a global terraform-block in the parent-level "main.tf" only, and from there this will affect all other "main.tf" - files in the subfolders.

Answer 1

I think the main thing to know here is that tflint is a configurable, pluggable Terraform configuration linter which happens to include an opinionated starting set of rules, but that set of rules is not "official" in the sense of being globally recommended by the creators of Terraform. If you disagree with anything it requires then there's nothing wrong with turning off some of the rules.

With that said, I think it's still interesting to consider what the advantages are of including these extra version constraints so you can make an informed decision about whether to include them.

Terraform itself only uses these arguments to give direct feedback if you are using a version of Terraform or of a provider that isn't compatible with the modules you are using. An explicit error message about an unsupported version is often easier to understand and fix than the downstream errors that are likely to appear without that constraint, such as an error about a resource configuration that uses an argument that isn't supported (but is supported in some other version of the provider).

For that reason, it can be helpful to record using these configuration features the minimum version of Terraform and of providers that you've tested the module with, both for your own future reference and for the reference of anyone else who might use your module in future, if you're working in a team setting or are publishing a public module.

If you don't include an explicit version constraint then the module isn't wrong, it's just not giving a user of the module any information about what versions are required and so they'll need to find that out some other way, such as in the module's documentation or just by trying it to see what happens.

Including this information in each module is not a violation of the "DRY" principle because each module's compatibility with Terraform itself and with the providers it uses is independent. One module might use a feature only available in the very latest version of the hashicorp/aws provider, whereas another module might just use aws_instance which has been in the provider so long that there is no published version that doesn't include it. All of your modules might have the same requirements right now, but as you evolve your modules you will probably find that some of them end up requiring newer versions of the provider than others.

---

The tflint documentation echoes the reasons I mentioned above in its documentation about the two rules that you were warned about here:

• terraform_required_version
• terraform_required_providers

These are both in tflint's "recommended" ruleset and so are enabled by default.