A future-proof Terraform supplier definition

When defining the model of a Terraform supplier, don’t use > or => circumstances. You’ll run into troubles brought on by breaking modifications with the subsequent main launch. As a substitute, lock the foremost model of the Terraform supplier through the use of a ~> situation.

However let’s begin initially.

Drawback

When operating terraform apply to deploy a small change to a code base that I had not touched for some time, I bumped into the next error.

An argument named "enable_classiclink" is not anticipated right here.

Whereas debugging the problem, I discovered quite a bit about Terraform model constraints that you simply must also pay attention to to keep away from disagreeable surprises.

What occurred?

I wrote the next code a number of years in the past to create a VPC and another sources.

terraform {
  required_providers {
    aws = {
      supply = "hashicorp/aws"
      model = "3.76.0"
    }
  }
}

supplier "aws" {
  area = "eu-west-1"
}

module "vpc" {
  supply = "terraform-aws-modules/vpc/aws"
  model = "3.19.0"

  identify = "demo"
  cidr = "10.0.0.0/16"

  azs = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
}

However, after updating to the newest AWS supplier model, I used to be caught with an An argument named "enable_classiclink" is just not anticipated right here. error.

terraform {
  required_providers {
    aws = {
      supply = "hashicorp/aws"
      model = "5.9.0"
    }
  }
}

supplier "aws" {
  area = "eu-west-1"
}

module "vpc" {
  supply = "terraform-aws-modules/vpc/aws"
  model = "3.19.0"

  identify = "demo"
  cidr = "10.0.0.0/16"

  azs = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
}

After some time, I came upon that the foremost launch 5.0.0 of the AWS supplier launched a number of breaking modifications. The change log contains the next entry.

useful resource/aws_default_vpc: With the retirement of EC2-Basic the enable_classiclink and enable_classiclink_dns_support attributes have been eliminated (

However, the terraform-aws-modules/vpc/aws module in model 3.19.0 nonetheless used the enable_classiclink_dns_support attribute, which brought about the error.

It seems that the terraform-aws-modules/vpc/aws module follows the foremost launch cycle of the AWS supplier. Nevertheless, the module doesn’t implement utilizing an AWS supplier with the supported main model.

Right here is how the terraform-aws-modules/vpc/aws module specifies the AWS supplier model.

terraform {
  required_version = ">= 0.13.1"

  required_providers {
    aws = {
      supply = "hashicorp/aws"
      model = ">= 3.73"
    }
  }
}

The model situation states that the module works with any AWS supplier model better or equal to 3.73. However that’s not the case as a result of every main model of the AWS supplier introduces breaking modifications.

Answer

When defining the required model, use the ~> situation as a substitute, which the Terraform documentation describes as follows:

“Permits solely the rightmost model part to increment. For instance, to permit new patch releases inside a selected minor launch, use the complete model quantity: ~> 1.0.4 will permit set up of 1.0.5 and 1.0.10 however not 1.1.0. That is often known as the pessimistic constraint operator.” (see Terraform: Model Constraints)

Again to the instance from above, the terraform-aws-modules/vpc/aws module ought to specify the AWS supplier as follows.

terraform {
  required_version = ">= 0.13.1"

  required_providers {
    aws = {
      supply = "hashicorp/aws"
      model = "~> 3.0"
    }
  }
}

Doing so would decide the newest model of the AWS supplier with main model 3. Newer main variations (4 or 5) with potential breaking modifications aren’t supported.

Be aware that this method requires all components of your Terraform configuration -including all of the modules you use- to make use of the identical main supplier variations. Alternatively, you could possibly use instruments like terragrunt that execute modules individually.