[JBerlinsky]

I'm not sure I follow the use case here. Perhaps it's just a function of my use cases for Terraform.

Terraform comes with `terraform plan`, which does a cursory validation of the infrastructure-as-code, diffs it against the current state of the world in various accounts, and reports back with what it expects to execute. While there are some cases where `terraform plan` succeeds and `terraform apply` errors, they tend to be cases that I don't think mocking would catch. For example:

- Certain AWS resource naming restrictions are not handled by `terraform plan`, but are caught by the AWS API, causing `terraform apply` to fail.

- The validity of AWS ACM certificates (issued vs pending) is not handled by `terraform plan` -- `plan` assumes that any certificate ARN provided is valid and issued, whereas the AWS API will error if the certificate is not valid, prompting `terraform apply` to fail.

There are plenty more examples (duplicate security group rules come to mind as a particularly egregious offender). I'm just not sure I see what value this provides -- if I'm missing something, please do let me know!

[diegopacheco]

All fare and reasonable points JBerlinsky! All you said make sense to me.

IMHO the main use cases for me is: - Speed up development time by doing tests locally - don't need to commit and wait a build kick it and see whats wrong. - Able to be part of the bigger scheme where you can test your whole "infrastructure" or part of it at least we still limited by localstack.

[JBerlinsky]

To your points:

>> - Speed up development time by doing test locally - don't need to commit and wait a build kick it and see whats wrong

Combined with the article linked, it sounds like you're working in an environment where the only machine authorized to interact with AWS, or retain the Terraform statefile, is a Jenkins build server. Might I suggest investigating Terraform Enterprise (despite the name, it's rather affordable, for what you're getting)? TFE integrates with Github (and other VCS) pull requests, allowing a pull request to trigger a `terraform plan`. This gives a pretty good understanding of whether your changes are going to succeed or not, and are pretty quick to run -- I work on some rather large projects, and have never waited more than a few minutes for a plan to complete.

If you're allowed to pull down the statefile, you can also just run `terraform state pull > terraform.tfstate && terraform plan`.

>> - Able to be part of the bigger scheme where you can test your whole "infrastructure" or part of it at least we still limited by localstack.

In my experience, mocking systems like `localstack` are never quite up to the "standard" of the systems they intend to mock (AWS in this case). Of particular note, AWS's APIs, especially for newer products, tend to have lots of "gotchas" that are undocumented or hard to trace back -- things that are extremely unlikely to be covered well in a mocking framework.

If this works well for you, great! Just giving my two cents, as someone who has thought a lot about this and wound up right back at `terraform plan`.

[diegopacheco]

In the end of the day is about COST but we could have more machines doing builds and better ones but still takes more time and effort them being local. Terraform enterprise is not available for me. Since my project just uses Open Source besides AWS.

AWS moves pretty FAST, but I don't know anything better than LocalStack fro AWS mocking.

[diegopacheco]

I Also understand this is far from perfect and I appreciate all your comments. I just wish AWS had something like localstack with all endpoints mocked would make everybody life so much better. Not to mention if they could use same(consistent) names for everything i.e API, CLI, BOTO etc...

[JBerlinsky]

You might also want to look into https://github.com/runatlantis/atlantis, which provides the benefits of Terraform Enterprise, in an open-source, self-hosted format.

[diegopacheco]

I did not know that one - looks pretty nice. Thanks for sharing!

[JBerlinsky]

My pleasure! At the end of the day, whatever works best for your workflow is ideal, of course.

[diegopacheco]

I did not know that one - looks pretty nice. Thanks for sharing!