It is time to start looking at the next new release of Terraform, the current latest and greatest (at time of writing) version is 1.3.8, was released on the 9th of February. This version was a minor bug-fixing release and should not change any current behaviour of your code base. We have outlined the bugs as taken from the release site in full below:
- Fixed a rare bug causing inaccurate before_sensitive / after_sensitive annotations in JSON plan output for deeply nested structures. This was only observed in the wild on the rancher/rancher2 provider, and resulted in glitched display in Terraform Cloud’s structured plan log view. (#32543)
- A variable only referenced by an output precondition error_message may be missing during evaluation (#32464)
- Removing a NestingSingle block from configuration results in an invalid plan (#32463)
- Null module outputs could be dropped, causing evaluation errors when referring to those module attributes (#32583)
- Fix terraform crash when applying defaults into a collection with dynamic type constraint. (#32454)
- Updated to newer github.com/mitchellh/cli version, in turn bringing in updates for several indirect dependencies with known security issues. (#32609)
- Fix case where the first plan to use a new remote state could be applied twice, corrupting the state (#32614)
You can find detailed output on each of the bugfixes by clicking the appropriate bug number. but that is not what this article is about!
Terraform 1.4.0-Beta 1
However, the big news is that Terraform 1.4 is just around the corner; with the release of v1.4.0-beta1 Hashicorp are almost ready to release to the wild. HashiCorp like most software companies use a semantic versioning systems 1(major).x(minor).x(bugfix). As version 1.4.0 is a minor release there should be no breaking changes, only feature releases and bug fixes; as breaking changes should only occur with a major version uplift. However, there are significant “Upgrade Notes” attached to this uplift that skirt very close to the breaking change in the behaviour bar.
There are two changes in the behaviour of textencodebase64 relating to the encoding of the euro symbol, a change in the way that terraform init will interpret a hostname portion of a provider source address. This changes behaviour to match that expected by the new WHATWG URL spec’s rules for interpreting non-ASCII domain names changes. The issue is that there may be issues relating to a punycode error. The final change is that HashiCorp have rewritten terraform plan, this one skirts so close to the border of breaking change as to be considered an incursion. Especially with the comment “Users are encouraged to file reports if they notice material differences, or encounter any bugs or panics during their normal execution of Terraform”.
There a several bug fixes: reprinted below
- The module installer will now record in its manifest a correct module source URL after normalization when the URL given as input contains both a query string portion and a subdirectory portion. Terraform itself doesn’t currently make use of this information and so this is just a cosmetic fix to make the recorded metadata more correct. (#31636)
- config: The yamldecode function now correctly handles entirely-nil YAML documents. Previously it would incorrectly return an unknown value instead of a null value. It will now return a null value as documented. (#32151)
- Ensure correct ordering between data sources and the deletion of managed resource dependencies. (#32209)
- Fix Terraform creating objects that should not exist in variables that specify default attributes in optional objects. (#32178)
- Fix several Terraform crashes that are caused by HCL creating objects that should not exist in variables that specify default attributes in optional objects within collections. (#32178)
- Fix inconsistent behaviour in empty vs null collections. (#32178)
- terraform workspace now returns a non-zero exit when given an invalid argument (#31318)
- Terraform would always plan changes when using a nested set attribute (#32536)
- Terraform can now better detect when complex optional+computed object attributes are removed from configuration (#32551)
- A new methodology for planning set elements can now better detect optional+computed changes within sets (#32563)
- Fix state locking and releasing messages when in -json mode, messages will now be written in JSON format (#32451)
As with the fixes included in the latest stable release if you want to know more click on the individual bug numbers.
Now for the fun bit, feature enhancements. This is what minor release are made for. What is new. What has made our lives easier, what can we do now that we could not do before?
There are two new changes that I am particularly excited about; the first is terraform_data, this is a new built in managed resource that can be used to replace the use of null_resource which it incorporates and enhances, it can be used to hold any type of data, it has 4 attributes, these being:
- id – this is a unique computed string
- triggers_replace: a value that wil trigger the replacement when changed
- input: a value (can be of any type) that will be reflected in the output.
- output: an output that is computed from the value of the input
This will be very useful for storing arbitrary values in State like a git commit hash value or pipeline commit.
The second is the addition of the –or-create value; this option will make the automatic creation of new workspaces much simpler in CI/CD environments, currently, the method used in pipelines is a workaround where you will issue the following: terraform workspace select test || terraform workspace new test, this batch string, however, has limitations when using the terraform docker image that does not handle shell scripts by design. This causes issues because using workspace new will result in an error if the workspace already exists and workspace select will error out if it does not.
This additional option will allow the command to natively test for the existence of a workspace and if present enter it, and if not create it and then enter it. Personally, I can see this being used a lot in my pipeline automation.
Another interesting enhancement is a change to terraform plan, it will be able to store a plan file if when it encounters errors, this can later be inspected to help identify those errors. This is another very useful enhancement.
One security enhancement is the masking of sensitive interactive inputs. For example, the request for a password. This will make my security peeps happy.
There are several welcome enhancements to Terraform Cloud and Enterprise around the deletion of workspaces. Now when any attempt to delete a workspace without the inclusion of the -force option the new safe delete API will undertake more detailed checks to confirm that the workspace is not locked, or if its state file is in the process of being updated. For further details the proposed documentation for this feature is here.
There is a change to the local-exec provisioner block with the addition of a -quiet argument, if this is set to true terraform will not print to stout the entire command during plan.
The final change of interest is the surrounding yamlencode, since the functions’ introduction it has been marked as experimental, from 1.4 onwards, it is mainstream and subject to the standard v1.x compatibility promises, if you have been using this feature in your code set there should be no requirements to change anything as the functionality is the same as v1.3.
The majority of other enhancements are surrounding error message displaying and these are a welcome improvement, any clearing of the water surrounding error messages should be applauded, loudly and from the highest point in the village.
For a minor release, there are a lot of new functionality and improvements. Personally, the updates to the workspace command will simplify pipelines significantly, the new terraform_data managed resource had vast potential. The masking of sensitive input to stout may seem trivial but it is something that has concerned me for a while, any clear display of a password entry should be guarded against, so again well done HashiCorp on that one. The only issue I have is that this release skirts very close to crossing the boundary of breaking changes that should be reserved for a major release. But all in all not bad.