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
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.
Summary
Native terraform since v0.14 supports terraform providers lock file. The
terraspace initcommand 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
and the subsequent lock file generated after init:
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 version5.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 initcommands should check if the lock file exists in the main folder and override the lock file in the cache folder beforeterraform initis run.The
terraspace init -upgradecommands 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.