One of Terraform's unique features and greatest pains is state management. In other forms of software engineering, you can effectively avoid side effects or other forms of hidden inputs and outputs. You can use fixtures for data and mock services. But not so much with infrastructure management code, especially when using Terraform. For this we are always taking the state as input to our code in addition any user-supplied parameters.

Much work as gone into being able to store, inspect and manipulate this state, but there is still a need for ways to better integrate those with normal version control based workflows. Which leads us to…

tfmigrate: A Terraform state migration tool

tfmigrate addresses this critical gap in terraform tooling - integration state manipulation with asynchronous workflows.

The the problem is this - image you are working on a team that uses pull requests and some sort of continuous delivery mechanism to apply your Terraform changes. You edit your code, work through a code review and merge process and then an automated process will apply the changes.

If you have a change that requires a state manipulation, like a move or delete, at what point do you do that? Before the PR? That means any concurrent changes will see the new state before the new code. Just before merging? Ok but now you have a manual step and what if it breaks something? Are merges done automatically. Good luck.

Here's the thing– Terraform should handle this. There has been some discussion of including state migrations in the language, but no visible work so far and apparently none before 1.0.

So enter tfmigrate. If you have rolled your own delivery pipeline (ie you are not on Terraform Cloud or Enterprise) tfmigrate could be made to fill this gap.

You can write migrations in hcl and use tfmigrate as part of your pipeline, making this process much smoother.

OPA is to Policy Automation as Terraform is to IaC

Terraform has become the dominant tool for many infrastructure-as-code workflows. Its combination of declarative approach, provider-agnosticism and ecosystem grown have lead to growing adoption.

Ryan Fee from Scalr argues here that Open Policy Agent (OPA) is doing the same for policy-as-code.

Like Terraform, OPA and its language, Rego, are domain-agnostic, declarative and have a growing ecosystem.

Notable Releases

v0.13.4 · terraform

Two small changes and a few bug fixes in this release.

First, as previously reported, the built-in vendor-based provisioners are now deprecated and will be removed in 0.15. 

Second, Terraform will now complain about more interpolation-only expressions, like "${foo}", which has been deprecated since 0.12 was released.

HashiCorp’s Homebrew Tap

If you are on a Mac (or use linuxbrew), you can now install Hashicorp tools through an official Homebrew tap. Note that you have been able to use homebrew's main repository to install for a long time, but now the builds will be canonical and signed by Hashicorp.

v3.8.0 · terraform-provider-aws

New resources- aws_datasync_location_fsx_windows (#12686), aws_route53_resolver_query_log_config (#14897) and aws_route53_resolver_query_log_config_association (#14901)

New data sources - aws_rds_engine_version (#15228), aws_docdb_engine_version (#15253), aws_neptune_engine_version (#15259) an daws_workspaces_image (#11428)

A large number of enhancements and bug fixes as well