feat(terraform)!: S3 native state locking (requires TF >= 1.11)#92
Open
gpazevedo wants to merge 1 commit intoawslabs:mainfrom
Open
feat(terraform)!: S3 native state locking (requires TF >= 1.11)#92gpazevedo wants to merge 1 commit intoawslabs:mainfrom
gpazevedo wants to merge 1 commit intoawslabs:mainfrom
Conversation
Replace DynamoDB-based state locking with Terraform 1.11's native S3 locking (use_lockfile). Simplifies prerequisites (one fewer AWS resource) and enables a documented state rollback procedure via S3 bucket versioning -- a capability the project previously lacked. Changes: - Bump required_version to >= 1.11.0 (needed for stable use_lockfile) - Ship backend.tf.example with S3-only locking; prereqs add versioning and public-access-block on the state bucket - Add "Rolling back state" and "Migrating from DynamoDB-only locking" subsections to infra-terraform/README.md (two-phase dual-lock rollout) - Update docs/TERRAFORM_DEPLOYMENT.md Terraform prerequisite version SemVer: this is a breaking change for users pinned to Terraform < 1.11, so it targets a 0.5.0 release. Precedent: CHANGELOG 0.2.0 (Python 3.8 -> 3.11 min) and 0.3.1 (Next.js -> Vite migration). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
use_lockfile), removing one AWS resource from the state-backend prerequisites.terraform statesurgery.required_versionto>= 1.11.0across root and all moduleversions.tf.Breaking change & SemVer
This raises the minimum Terraform version from
1.5.0to1.11.0, so it targets a 0.5.0 release per SemVer. Precedent inCHANGELOG.md:0.2.0— Python minimum bumped 3.8 → 3.110.3.1— frontend framework migration (Next.js → Vite)CHANGELOG entries added under
[Unreleased]:use_lockfile; Terraform>= 1.11requiredMigration
Existing deployments on the DynamoDB-based backend follow a two-phase rollout documented in
infra-terraform/README.md(section: Migrating from DynamoDB-only locking):dynamodb_tablealongsideuse_lockfile = trueuntil every operator has pulled the new config and is on Terraform>= 1.11.dynamodb_table,terraform init -reconfigure, thenaws dynamodb delete-table.Bucket versioning is not retroactive; enable it on the state bucket before relying on the rollback procedure.
Test plan
terraform init -migrate-stateon a fresh bucket withuse_lockfile = truesucceeds.terraform init -reconfigurewith dual-lock config (bothdynamodb_tableanduse_lockfile) succeeds on an existing DynamoDB-backed state.aws dynamodb delete-tablesucceeds.copy-objectwith priorversionId, thenterraform plan) restores a prior state withoutterraform statesurgery.🤖 Generated with Claude Code