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

Static lock table #2

Open
nwhite-sf opened this issue Jul 25, 2017 · 2 comments
Open

Static lock table #2

nwhite-sf opened this issue Jul 25, 2017 · 2 comments
Labels

Comments

@nwhite-sf
Copy link

I noticed that lock_table is hard coded. Why not have it based on the environment (prd, dev, qa) so that you can work on these in a parallel fashion?

@josh-padnick
Copy link

The lock_table property (which by the way I now realize is deprecated in favor of the dynamodb_table property!) specifies a DynamoDB table, but that table will have one row or entry for each unique Terraform state. Therefore, as long as you keep the Terraform states in your various environments separate, then you'll have a unique lock on each and can work in parallel as you desire.

@brikis98
Copy link
Member

I suspect that even if you use the same DynamoDB table for locks, if the key parameter is different, then the lock will be different too. Since you have different state files for each environment, and therefore different key values, you shouldn't be seeing lock contention.

Are you seeing something different?

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

No branches or pull requests

3 participants