14 KiB
0.12.2 (Unreleased)
NEW FEATURES:
range
function for generating a sequence of numbers as a list [GH-21461]yamldecode
and experimentalyamlencode
functions for working with YAML-serialized data [GH-21459]
ENHANCEMENTS:
- backend/http: implement retries for the http backend [GH-19702]
BUG FIXES:
- command/show: use the state snapshot included in the planfile when rendering a plan to json [GH-21597]
- core: Don't panic when encountering an invalid
depends_on
[GH-21590]
0.12.1 (June 3, 2019)
BUG FIXES:
- core: Always try to select a workspace after initialization (#21234)
- command/show: fix inconsistent json output causing a panic [#21541]
- config:
distinct
function no longer panics when given an empty list (#21538) - config: Don't panic when a
version
constraint is added to a module that was previously initialized without one (#21542) - config:
matchkeys
function argument type checking will no longer fail incorrectly during validation (#21576) - backend/local: Don't panic if an instance in the state only has deposed instances, and no current instance (#21575)
0.12.0 (May 22, 2019)
This is the aggregated summary of changes compared to v0.11.14. If you'd like to see the incremental changelog through each of the v0.12.0 prereleases, please refer to the v0.12.0-rc1 changelog.
The focus of v0.12.0 was on improvements to the Terraform language made in response to all of the feedback and experience gathered on prior versions. We hope that these language improvements will help to make configurations for more complex situations more readable, and improve the usability of re-usable modules.
However, an overhaul of this kind inevitably means that 100% compatibility is not possible. The updated language is designed to be broadly compatible with the 0.11 language as documented, but some of the improvements required a slightly stricter parser and language model in order to resolve ambiguity or to give better feedback in error messages.
If you are upgrading to v0.12.0, we strongly recommend reading the upgrade guide to learn the recommended upgrade process, which includes a tool to automatically upgrade many improved language constructs and to indicate situations where human intuition is required to complete the upgrade.
Incompatibilities and Notes
-
As noted above, the language overhaul means that several aspects of the language are now parsed or evaluated more strictly than before, so configurations that employ workarounds for prior version limitations or that followed conventions other than what was shown in documentation may require some updates. For more information, please refer to the upgrade guide.
-
In order to give better feedback about mistakes, Terraform now validates that all variable names set via
-var
and-var-file
options correspond to declared variables, generating errors or warnings if not. In situations where automation is providing a fixed set of variables to all configurations (whether they are using them or not), useTF_VAR_
environment variables instead, which are ignored if they do not correspond to a declared variable. -
The wire protocol for provider and provisioner plugins has changed, so plugins built against prior versions of Terraform are not compatible with Terraform v0.12. The most commonly-downloaded providers already had v0.12-compatible releases at the time of v0.12.0 release, but some other providers (particularly those distributed independently of the
terraform init
installation mechanism) will need to make new releases before they can be used with Terraform v0.12 or later. -
The index API for automatic provider installation in
terraform init
is now provided by the Terraform Registry atregistry.terraform.io
, rather than the indexes directly onreleases.hashicorp.com
. The "releases" server is still currently the distribution source for the release archives themselves at the time of writing, but that may change over time. -
The serialization formats for persisted state snapshots and saved plans have changed. Third-party tools that parse these artifacts will need to be updated to support these new serialization formats.
For most use-cases, we recommend instead using
terraform show -json
to read the content of state or plan, in a form that is less likely to see significant breaking changes in future releases. -
terraform validate
now has a slightly smaller scope than before, focusing only on configuration syntax and type/value checking. This makes it safe to run in unattended scenarios, such as on save in a text editor.
New Features
The full set of language improvements is too large to list them all out exhaustively, so the list below covers some highlights:
-
First-class expressions: Prior to v0.12, expressions could be used only via string interpolation, like
"${var.foo}"
. Expressions are now fully integrated into the language, allowing them to be used directly as argument values, likeami = var.ami
. -
for
expressions: This new expression construct allows the construction of a list or map by transforming and filtering elements from another list or map. For more information, refer to thefor
expressions documentation. -
Dynamic configuration blocks: For nested configuration blocks accepted as part of a resource configuration, it is now possible to dynamically generate zero or more blocks corresponding to items in a list or map using the special new
dynamic
block construct. This is the official replacement for the common (but buggy) unofficial workaround of treating a block type name as if it were an attribute expecting a list of maps value, which worked sometimes before as a result of some unintended coincidences in the implementation. -
Generalised "splat" operator: The
aws_instance.foo.*.id
syntax was previously a special case only for resources withcount
set. It is now an operator within the expression language that can be applied to any list value. There is also an optional new splat variant that allows both index and attribute access operations on each item in the list. For more information, refer to the Splat Expressions documentation. -
Nullable argument values: It is now possible to use a conditional expression like
var.foo != "" ? var.foo : null
to conditionally leave an argument value unset, whereas before Terraform required the configuration author to provide a specific default value in this case. Assigningnull
to an argument is equivalent to omitting that argument entirely. -
Rich types in module inputs variables and output values: Terraform v0.7 added support for returning flat lists and maps of strings, but this is now generalized to allow returning arbitrary nested data structures with mixed types. Module authors can specify an expected type constraint for each input variable to allow early type checking of arguments.
-
Resource and module object values: An entire resource or module can now be treated as an object value within expressions, including passing them through input variables and output values to other modules, using an attribute-less reference syntax, like
aws_instance.foo
. -
Extended template syntax: The simple interpolation syntax from prior versions is extended to become a simple template language, with support for conditional interpolations and repeated interpolations through iteration. For more information, see the String Templates documentation.
-
jsondecode
andcsvdecode
interpolation functions: Due to the richer type system in the new configuration language implementation, we can now offer functions for decoding serialization formats.jsondecode
is the opposite ofjsonencode
, whilecsvdecode
provides a way to load in lists of maps from a compact tabular representation. -
Revamped error messages: Error messages relating to configuration now always include information about where in the configuration the problem was found, along with other contextual information. We have also revisited many of the most common error messages to reword them for clarity, consistency, and actionability.
-
Structual plan output: When Terraform renders the set of changes it plans to make, it will now use formatting designed to be similar to the input configuration language, including nested rendering of individual changes within multi-line strings, JSON strings, and nested collections.
Other Improvements
-
terraform validate
now accepts an argument-json
which produces machine-readable output. Please refer to the documentation for this command for details on the format and some caveats that consumers must consider when using this interface. (#17539) -
The JSON-based variant of the Terraform language now has a more tightly-specified and reliable mapping to the native syntax variant. In prior versions, certain Terraform configuration features did not function as expected or were not usable via the JSON-based forms. For more information, see the JSON Configuration Syntax documentation.
-
The new built-in function
templatefile
allows rendering a template from a file directly in the language, without installing the separate Template provider and using thetemplate_file
data source. -
The new built-in function
formatdate
, which is a specialized string formatting function for creating machine-oriented timestamp strings in various formats. -
The new built-in functions
reverse
, which reverses the order of items in a list, andstrrev
, which reverses the order of Unicode characters in a string. -
A new
pg
state storage backend allows storing state in a PostgreSQL database. -
The
azurerm
state storage backend supports new authentication mechanisms, custom resource manager endpoints, and HTTP proxies. -
The
s3
state storage backend now supportscredential_source
in AWS configuration files, support for the new AWS regionseu-north-1
andap-east-1
, and several other improvements previously made in theaws
provider. -
The
swift
state storage backend now supports locking and workspaces.
Bug Fixes
Quite a few bugs were fixed indirectly as a result of improvements to the underlying language engine, so a fully-comprehensive list of fixed bugs is not possible, but some of the more commonly-encountered bugs that are fixed in this release include:
-
config: The conditional operator
... ? ... : ...
now works with result values of any type and only returns evaluation errors for the chosen result expression, as those familiar with this operator in other languages might expect. -
config: Accept and ignore UTF-8 byte-order mark for configuration files (#19715)
-
config: When using a splat expression like
aws_instance.foo.*.id
, the addition of a new instance to the set (whoseid
is therefore not known until after apply) will no longer cause all of the other ids in the resulting list to appear unknown. -
config: The
jsonencode
function now preserves the types of values passed to it, even inside nested structures, whereas before it had a tendency to convert primitive-typed values to string representations. -
config: The
format
andformatlist
functions now attempt automatic type conversions when the given values do not match the "verbs" in the format string, rather than producing a result with error placeholders in it. -
config: Assigning a list containing one or more unknown values to an argument expecting a list no longer produces the incorrect error message "should be a list", because Terraform is now able to track the individual elements as being unknown rather than the list as a whole, and to track the type of each unknown value. (This also avoids any need to place seemingly-redundant list brackets around values that are already lists, which would now be interpreted as a list of lists.)
-
cli: When
create_before_destroy
is enabled for a resource, replacement actions are reflected correctly in rendered plans as+/-
rather than-/+
, and described as such in the UI messages. -
core: Various root causes of the "diffs didn't match during apply" class of error are now checked at their source, allowing Terraform to either avoid the problem occurring altogether (ideally) or to provide a more actionable error message to help with reporting, finding, and fixing the bug.
For information on v0.11 and prior releases, please see the v0.11 branch changelog.