Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for native terraform provider lock file #350

Open
jeffery opened this issue Mar 26, 2024 · 0 comments
Open

Add support for native terraform provider lock file #350

jeffery opened this issue Mar 26, 2024 · 0 comments

Comments

@jeffery
Copy link

jeffery commented Mar 26, 2024

Summary

Native terraform since v0.14 supports terraform providers lock file. The terraspace init command does generate this file but the file is created in the generated cache folder and cannot be re-used for different environments unless the cache folder is maintained in scm.

Motivation

Not having the ability to lock the provider versions can potentially create in-consistencies in the infrastructure between terraform apply's on different environments.

Take the following provider configuration as an example

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

  required_version = "~> 1.6"
}

and the subsequent lock file generated after init:

# This file is maintained automatically by "tofu init".
# Manual edits may be lost in future updates.

provider "registry.opentofu.org/hashicorp/aws" {
  version     = "5.42.0"
  constraints = "~> 5.0"
  hashes = [
    "h1:prGbTSD4n4cD0zHJDdzF+k1u0s1yXA30DZPX/2x2u88=",
    "zh:242edae302f4ba676ecf24150ca4a02ea517e57fcf96a41fca07c5f3d3296185",
    "zh:272b95720a007f9069d3f9595b3f0b38a77cc6aeb3a281afb31eeea8a9df29f1",
    "zh:33c2a8420f6eac31f25f6ba847852d3bbca158289cd7edfd62de70ab6ee8ed89",
    "zh:47a38a303d406b50c56ef91f2c7549f0992f23d37ba73d4477f0d45cdb7f5a06",
    "zh:68addeeef736f0cc6e50eb645e56b4cfa4fd35f704234221606147f20da86a54",
    "zh:9f24cb99c19f0f5a5312dee1ce35c1c7de159524e0a54cb0eb9cd6ead96ca181",
    "zh:ae5b851ac9c42551113829e5b482313b10f9acb1273badc83098efd00b07c4ca",
    "zh:d56839fcdb7067a5be6ce8981ace30595945c914cc0104dedaaab4280de57456",
    "zh:f7e71d1a5b4a77393079768afc8d97e59b6c2c1c49a205745f923227b177e457",
    "zh:f8735ac98ee3b670049dac3f51b0418bb176786799565b3deeffbfc356e3ab60",
  ]
}

In the above example the version constraint for aws provider we used was version = "~> 5.0" which as of today downloaded the latest available provider version 5.42.0.

While creating infrastructure we would potentially have multiple environments to deploy this terraform code to. If we deploy the code today, terraform will use the above provider version. However we may not deploy the code to a higher environment the same day. We possibly would deploy the same code at a different time or by a different user or even a pipeline. With the lack of a provider lock file, terraspace init will potentially will pull down the latest provider version before the terraform stacks are applied.

Guide-level explanation

The proposal is to maintain the provider lock file outside of the cache folder.

When terraspace init <stack name> is executed, terraform will generate the lock file for the stack in the cached folder. This lock file needs to be copied back into the main stack folder so that it can be stored into the SCM.

Subsequent terraspace init commands should check if the lock file exists in the main folder and override the lock file in the cache folder before terraform init is run.

The terraspace init -upgrade commands should re-generate the lock file.

See discussion at https://community.boltops.com/t/terraform-provider-lock-file/1167

Drawbacks

None

I don't see why we shouldn't do this as it brings terraspace close to native terraform functionality and increases adoption of terraspace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant