Terraform v0.14.0-rc1 Released

Terraform
1

Today we’ve released Terraform 0.14.0-beta1, which marks the start of the prerelease testing period for Terraform v0.14.

We plan to publish at least one more beta release and one release candidate before the final 0.14.0. During this period, we’d be very grateful if folks could try out the new features in this release and let us know if you see any unusual behavior.

We do not recommend using beta releases in production. While many of these features have seen some alpha testing prior to these beta releases, the betas will be the first exposure of some of this code to use-cases the Terraform team didn’t anticipate during that internal testing, and so there may well be bugs lurking which we’ll aim to address during the beta period.

The following sections describe some highlights of the 0.14 release, including links to other forum topics where you can see more details and where we invite you to share your feedback. We’ve locked this forum topic because we’d like to keep the feedback discussion attached to each individual functional area, so that the discussions are easier to follow. However, if you have any general feedback that isn’t covered by one of these topics we always welcome that via issues in our GitHub repository.

Concise Terraform Plan Output

Terraform 0.12 included a change in the way the plan output shows the planned changes, resulting in notably more verbose output when compared to Terraform 0.11. Terraform 0.14 will ship with a new concise diff format that aims to be a compromise between the 0.11 approach and the 0.12 approach, showing enough information to understand which objects are changing but without listing out all of the unchanged values.

Sensitive Input Variables

Some Terraform modules expect input variables whose values are considered sensitive. Terraform 0.14 includes a new syntax for marking an input variable as sensitive and also includes new behaviors in expression evaluation so that values that are derived from sensitive input variables can also be considered as sensitive.

These new mechanisms are focused on keeping sensitive values out of the UI so that they won’t be compromised by inclusion saved logs of UI output from previous runs.

Provider Dependency Lock File

Terraform 0.14’s terraform init will now generate a new file .terraform.lock.hcl that records which provider versions were selected by the installation process, and then subsequent calls to terraform init will make those same selections. This avoids situations where you might accidentally select a newer version of a provider and see different behavior that you can’t attribute to an intentional change.

Other Improvements

As usual, the 0.14 release includes a variety of other changes that are smaller in scope but hopefully still useful and helpful. For a full roster of changes in the 0.14 releases, refer to the 0.14 changelog.

View our draft upgrade guide

Download Terraform 0.14.0-rc1

2 Likes
2
3
4

Any word on what the path to going GA looks like?

5

@jurgenweber:

0.14.0beta2 should ship this week (~October 28th, 2020). If all goes well, RC1 to follow two weeks later and GA two weeks after that. :slight_smile:

3 Likes
6

nice 1, that is what I thought you would say. Amazing stuff. Thank you!

1 Like
7

Hi all!

Today we’ve released Terraform v0.14.0-beta2, which includes a number of bug fixes made in response to beta1 feedback, along with some small enhancements that didn’t quite get merged in time to be included in beta1.

After this beta, we intend to publish one release candidate prior to the final 0.14.0 release. We’d be very grateful if you would try out the new features either in beta2 or in the release candidate and let us know if you see any unusual behavior, so we can hopefully address it before the final release. As always, we do not recommend using beta releases in production.

The following is a partial list of some of the most important changes since beta1:

  • The beta2 release includes a few small tweaks to the syntax and structure of the dependency lock file, .terraform.lock.hcl. Some of those changes are not backward compatible with lock files generated by beta1 due to bugs in that release, so we recommend deleting any lock files that were created by beta1 before trying out beta2. (After 0.14.0 final we do intend for future releases to be backward-compatible with existing lock files, though.)

  • The mechanism for hiding sensitive values in the UI now has an experimental extension where it also considers the sensitivity flags defined by providers in resource type schemas. You can activate that behavior by declaring the provider_sensitive_addrs experiment:

    terraform {
  experiments = [provider_sensitive_attrs]
}

    We intend for this extension to remain experimental throughout the v0.14 series. Modules which export sensitive values in their output values must mark those outputs with sensitive = true, so this behavior may also require changes to your existing output value declarations.

  • There are two new functions alltrue and anytrue which are intended to make it easier to write custom variable validation rules that must apply for all elements in a collection. For example:

    variable "example" {
  type = list(string)
  
  validation {
    condition = alltrue([
      for s in var.example : s != ""
    ])
    error_message = "Empty strings are not allowed."
  }
}

  • There are two new functions textencodebase64 and textdecodebase64 which are, in a sense, generalizations of the existing base64encode and base64decode which allow you to choose specific character encodings rather than requiring UTF-8.

    The need for base64-encoded text is pretty rare in Terraform anyway, and base64-encoded text in other encodings is even rarer, but one area these can be particularly useful is in interacting with systems whose default character encoding is UTF-16, such as Microsoft Windows software or JavaScript-based applications.

The draft upgrade guide linked in the opening post of this forum topic remains relevant for v0.14.0-beta2, so please refer to that for any considerations to be aware of if you are testing with a configuration that was previously established with an earlier Terraform version.

3 Likes
8

All of this looks great. Really digging the opinionated fmt. However, I was surprised to see that it defaults to quoting resources and their names instead of leaving them unquoted. Is there any particular reason for this?

2 Likes
9
10

Hi @lijok,

As with everything in terraform fmt, the decision is generally arbitrary and based on existing practice. In the case of the block labels, the Terraform documentation has been showing those quoted going right back to the earliest release, and we typically make terraform fmt follow what was documented in order to minimize updates for those who were following what was shown in the examples.

Again though, there are rarely objective reasons for any of these style-only things… that’s the nature of a formatter like terraform fmt. For all of its behaviors there is no argument for an against them other than “that’s the style Terraform’s documentation typically followed”.

11

Today we released Terraform v0.14.0-rc1, which fixes a few bugs found in the earlier betas, along with some other changes prior to the final release.

We intend to publish Terraform 0.14.0 as our next release in this series. We’d appreciate any feedback you can give to make sure that we have a chance to address it before the final 0.14.0 ships. As always, we do not recommend using pre-release versions of Terraform in production.

Here are a few of the changes since the last beta:

  • We fixed some more bugs with the dependency lock file, which again means that users of previous v0.14.0-beta releases may need to delete their lock file before running terraform init.
  • Fixed missing sensitive value marking in the validate phase, allowing earlier diagnostic reports for invalid configurations.
  • Outputs from all modules were incorrectly displayed after an apply or when using the terraform output command. Now only root module outputs are shown.
  • The path.cwd, path.root, path.module, and terraform.workspace values were unavailable in provisioner blocks. These have been restored.

If this is the first 0.14.0 pre-release version you try, please see the draft upgrade guide, linked in the first post of this topic.

2 Likes
12
13

0.14.0beta2 should ship this week (~October 28th, 2020). If all goes well, RC1 to follow two weeks later and GA two weeks after that. :slight_smile:

Looks like we are nearing the 2 week mark since RC1. With holidays and everything though, I would totally understand if this stretches out. And of course, it’s also possible an RC2 would be necessary in case of substantial changes needed.

Any updates on what approximate timing is expected and if there’s an 0.14 RC2 or if we’ll go straight to GA?

Thanks so much for all you do! :pray:

14

Hi @aaronsteers1,

At the moment there is no plan for a second release candidate, but we are planning to hold the final release until next week because, as you noted, a majority of our team are based in the United States and so will have at least two company holiday days off this week.

Of course, as usual these details are subject to change if the context around them changes.

1 Like
15

In testing 0.14.0-rc1, I’ve come across an issues which appear to be a regression. Unless this is already tracked elsewhere, I’ll go ahead and open a new for this in github.

Issue: terraform output no longer respects newline characters

I used to get…

my_out = This is a
multiline
string.

but now I get:

my_out = This is a\nmultiline\nstring.

This is problematic since I have several modules which render outputs with URLs for the user to click on - those are now completely mashed and the multi-line output is no longer readable.

By chance, is this known/expected with 0.14.0-rc?

UPDATE: second issue regarding invalid auto-reformat:

I also noted that running terraform fmt on my existing project created a few syntax errors due to incorrect handling of parenthesis…

locals {
  value_a = ([
    [1,2,3],
    [1]
  ])
  value_b = 4
}

…becomes syntactically invalid after terraform fmt:

locals {
  value_a = ([
    [1, 2, 3],
    [1]
    ]
  ) value_b = 4
}

UPDATE: GitHub issues logged here and here.

1 Like
16

Sorry if this is the wrong place to raise a bug, but when running TF 14.0-rc1 on a fresh install of Mac OSX Big Sur I get terraform-provider-aws_v3.10.0_x5” cannot be opened because the developer cannot be verified., this is the same for all the providers and I need to going into system setting/security and manually add them as exceptions to get them to execute.

Secondly we have crash debug below:

panic: value is marked, so must be unmarked first
goroutine 17491 [running]:

github.com/zclconf/go-cty/cty.Value.assertUnmarked(...)

/go/pkg/mod/github.com/zclconf/go-cty@v1.7.0/cty/marks.go:123

github.com/zclconf/go-cty/cty.Value.True(0x3845b40, 0xc000134381, 0x313e600, 0xc004581c80, 0x3845b01)

/go/pkg/mod/github.com/zclconf/go-cty@v1.7.0/cty/value_ops.go:360 +0x52

github.com/zclconf/go-cty/cty.Value.False(...)

/go/pkg/mod/github.com/zclconf/go-cty@v1.7.0/cty/value_ops.go:369

github.com/hashicorp/hcl/v2.Index(0x3845c00, 0xc00e4707b0, 0x313e600, 0xc004b14a20, 0x3845b40, 0xc000134380, 0x2f69540, 0xc001d33c10, 0xc000c01400, 0x3845c00, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/ops.go:87 +0x6a8

github.com/hashicorp/hcl/v2.TraverseIndex.TraversalStep(...)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/traversal.go:273

github.com/hashicorp/hcl/v2.Traversal.TraverseRel(0xc00199a390, 0x2, 0x3, 0x3845c40, 0xc006a204c0, 0x3049520, 0xc00e25fe00, 0x0, 0x384ca40, 0x0, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/traversal.go:50 +0x122

github.com/hashicorp/hcl/v2.Traversal.TraverseAbs(0xc00199a380, 0x3, 0x4, 0xc004581860, 0xc006b05ef0, 0x13bfcaf, 0xc000134380, 0x3845b40, 0xc000134380, 0x1, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/traversal.go:81 +0x30e

github.com/hashicorp/hcl/v2/hclsyntax.(*ScopeTraversalExpr).Value(0xc0023653e0, 0xc004581860, 0x0, 0xa, 0xc00b5a2718, 0xc000134301, 0x3845b40, 0xc000134380, 0x2f69540)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/hclsyntax/expression.go:109 +0x65

github.com/hashicorp/hcl/v2/hcldec.(*AttrSpec).decode(0xc0030d2db0, 0xc000c01380, 0x0, 0x0, 0x0, 0xc004581860, 0x3845b40, 0xc000134380, 0x0, 0x0, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/hcldec/spec.go:205 +0x2ac

github.com/hashicorp/hcl/v2/hcldec.ObjectSpec.decode(0xc0030d2cf0, 0xc000c01380, 0x0, 0x0, 0x0, 0xc004581860, 0xc001c71740, 0x20, 0x20, 0xc004581a00, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/hcldec/spec.go:79 +0x237

github.com/hashicorp/hcl/v2/hcldec.decode(0x3844ac0, 0xc004581a00, 0x0, 0x0, 0x0, 0xc004581860, 0x3845900, 0xc0030d2cf0, 0x0, 0x0, …)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/hcldec/decode.go:21 +0x11b

github.com/hashicorp/hcl/v2/hcldec.Decode(...)

/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.7.0/hcldec/public.go:15

github.com/hashicorp/terraform/lang.(*Scope).EvalBlock(0xc00db567d0, 0x3844340, 0xc00e25e090, 0xc001c71a10, 0x1, 0x1, 0x0, 0x0, 0x0, 0x3845c01, …)

/home/circleci/project/project/lang/eval.go:67 +0x2ac

github.com/hashicorp/terraform/terraform.(*BuiltinEvalContext).EvaluateBlock(0xc00311dc70, 0x3844340, 0xc00e25e090, 0xc001c71a10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, …)

/home/circleci/project/project/terraform/eval_context_builtin.go:280 +0x2c5

github.com/hashicorp/terraform/terraform.(*EvalDiff).Eval(0xc006b07a98, 0x3881040, 0xc00311dc70, 0x0, 0x0, 0x0, 0x0)

/home/circleci/project/project/terraform/eval_diff.go:156 +0x27c

github.com/hashicorp/terraform/terraform.(*NodePlannableResourceInstance).managedResourceExecute(0xc007318df0, 0x3881040, 0xc00311dc70, 0x1037f05, 0x3549be0)

/home/circleci/project/project/terraform/node_resource_plan_instance.go:207 +0x58d

github.com/hashicorp/terraform/terraform.(*NodePlannableResourceInstance).Execute(0xc007318df0, 0x3881040, 0xc00311dc70, 0xc0061f0002, 0x3096de0, 0x33a66a0)

/home/circleci/project/project/terraform/node_resource_plan_instance.go:39 +0xd2

github.com/hashicorp/terraform/terraform.(*ContextGraphWalker).Execute(0xc00953bad0, 0x3881040, 0xc00311dc70, 0x3ae38300, 0xc007318df0, 0x0, 0x0, 0x0)

/home/circleci/project/project/terraform/graph_walk_context.go:127 +0xbc

github.com/hashicorp/terraform/terraform.(*Graph).walk.func1(0x33a66a0, 0xc007318df0, 0x0, 0x0, 0x0)

/home/circleci/project/project/terraform/graph.go:59 +0x962

github.com/hashicorp/terraform/dag.(*Walker).walkVertex(0xc00072d860, 0x33a66a0, 0xc007318df0, 0xc00e321080)

/home/circleci/project/project/dag/walk.go:387 +0x375

created by github.com/hashicorp/terraform/dag.(*Walker).Update

/home/circleci/project/project/dag/walk.go:309 +0x1246

!!! TERRAFORM CRASH !!!

Terraform crashed! This is always indicative of a bug within Terraform.

A crash log has been placed at “crash.log” relative to your current

working directory. It would be immensely helpful if you could please

report the crash with Terraform1 so that we can fix this.

When reporting bugs, please include your terraform version. That

information is available on the first line of crash.log. You can also

get it by running ‘terraform --version’ on the command line.

SECURITY WARNING: the “crash.log” file that was created may contain

sensitive information that must be redacted before it is safe to share

on the issue tracker.

!!! TERRAFORM CRASH !!!

17

It is, but thanks for checking! Please report these bugs on GitHub and we’ll get right to looking at them. Thanks!

18

I’m trying to test in my CI/CD environment but I don’t see an apt version for the rc1 release. I followed the instructions here:

$ apt-get update
$ apt-get install -y lsb-core apt-transport-https software-properties-common
$ curl -fsSL https://apt.releases.hashicorp.com/gpg | apt-key add -
$ apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
$ apt-get update && apt-get -y install terraform=0.14.0-rc1
...
E: Version '0.14.0-rc1' for 'terraform' was not found

Am I doing something incorrect - perhaps need to add a different apt repository, or perhaps RC isn’t published to apt?

Update: I was able to work around this with a manual wget and unzip. I’m still interested to know if there’s a way to get prereleases with apt-get, but I’m unblocked. In case this is helpful to anyone else:

export TF_VERSION=0.14.0-rc1
echo "Installing terraform version $TF_VERSION..."
wget https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip
unzip terraform_${TF_VERSION}_linux_amd64.zip
mv terraform /usr/local/bin/
terraform --version
19

Hi @aaronsteers1,

The alternative package repositories are maintained by a central team at HashiCorp rather than by our team directly so I’m honestly not 100% sure of the behavior here but I suspect these repositories only pick up stable releases on the assumption that folks using these repositories are likely to be trying to use the software in production and would thus not want to end up inadvertently using a prerelease just because it happens to be the highest available version number.

Installing the .zip packages directly from releases.hashicorp.com is the expected way to participate in the beta/rc process, in any case.

20

Terraform v0.14.0 final is now released!

3 Likes