Skip to content

Conversation

@hubbcaps
Copy link
Contributor

For some reason my dynamoDB config is constantly being clobbered and even with the creation of the default lock table, I keep getting non existent table errors from tflocal, and it's blocking my on boarding as a new enterprise customer.

Since DynamoDB is deprecated anyways, here's support for use_lockfile which is the new standard and simply uses an object in the state s3 bucket to handle locking.

This PR switches to use_lockfile as the new standard config, and if someone wants to override it with a bucket config, we yank out use_lockfile and throw their table into the previous logic path of get_or_create on the table they have configured.

Let me know if there's any fixes you'd like added, but I think its pretty solid.

https://developer.hashicorp.com/terraform/language/backend/s3#enabling-s3-state-locking

Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks a lot for your contribution! The change looks sound, I'm just a bit worried into setting default values for versions of Terraform that don't support use_lockfile yet.

After looking more into S3 Backend State Locking, it seems it is actually an opt-in behavior in Terraform: https://developer.hashicorp.com/terraform/language/backend/s3#state-locking

I'm not sure why we are setting the DynamoDB locking on by default, but do you think it would actually be better to just remove it (as it is opt-in, it should not be "on" by default? ) and let users decide if they want to use it?

We could keep the custom logic you've modified to actually create the DynamoDB table if it is configured by the user, but otherwise just not set it on by default? It doesn't seem to be something needed anyway when working in local mode.

I'd like to hear if that would also solve your issue, and if you think that would be an acceptable solution?

@hubbcaps
Copy link
Contributor Author

Yeah that seems like a completely reasonable idea, only include them if the user is providing them, otherwise we just run with no locking, as really it shouldn't be needed in a local setup.

I'll get those changes up to, and fix the overzealous linting 🫠

@hubbcaps
Copy link
Contributor Author

That's been changed up @bentsku, good call, looks much more elegant.

@bentsku bentsku self-requested a review May 16, 2025 15:37
Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for addressing the comments, I'll push the update/readme changes and merge/release a new version 😄 thanks a lot for bringing this discussion up!

@bentsku
Copy link
Contributor

bentsku commented May 16, 2025

@hubbcaps I've updated the readme/bumped the version, and as I was there, quickly added a test for it on the branch, hope that's okay 😄

@hubbcaps
Copy link
Contributor Author

Absolutely dude, testing is always good 😁

@bentsku bentsku changed the title Add support for use_lockfile for s3 backend Fix s3 backend setting DynamoDB state lock on by default May 16, 2025
@bentsku bentsku merged commit 1a53701 into localstack:main May 16, 2025
3 checks passed
@bentsku
Copy link
Contributor

bentsku commented May 16, 2025

Awesome, thanks a lot @hubbcaps again for the contribution and welcome to the contributors list 😄

I've just released terraform-local v0.22.0, so hopefully that should fix the issue for you. If not, please feel free to ping me directly! Thanks again 🙏

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

Successfully merging this pull request may close these issues.

2 participants