8. Terraform 0.12. What? When?
● What happened?
● Backward compatible?
● What does it mean for provider
developers?
● What does it mean for module developers?
● When shall I migrate?
9. CHANGELOG.md - backward compatibility
This release includes a revamped implementation of the configuration language that aims to address a wide
array of feedback and known issues with the configuration language handling in prior versions. In order to
resolve some ambiguities in the language, the new parser is stricter in some ways about following what was
previously just idiomatic usage, and so some unusual constructs will need to be adjusted to be accepted by
the new parser.
The v0.12.0 final release will include a more complete language upgrade guide and a tool that can recognize
and automatically upgrade common patterns for the new parser and new idiomatic forms.
More info at
https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md#0120-alpha1-october-19-2018
10. Providers
This release introduces new wire protocols for provider and provisioner plugins and a new automatic
installation method for provider plugins. At the time of release there are no official plugin releases
compatible with these new protocols and so automatic provider installation with terraform init is not
functional. Instead, the v0.12.0-alpha1 distribution archives contain bundled experimental provider builds
for use with the alpha.
11. Modules
Module authors will need to complete several steps to get their modules ready for v0.12.
1. Follow the steps in "Upgrading Terraform configurations" above to get the module code upgraded
2. The migration tool will automatically add a >= 0.12.0 Terraform version constraint to indicate that the
module has been upgraded to use v0.12-only features.
3. If the module is published in a module registry, publish a new major version of the module to indicate
that the new version is not compatible with older versions of Terraform. If you are not using a registry,
be sure that downstream consumers of the module are aware of the update.
Module consumers can then upgrade to the new versions of the module by upgrading their configurations to
0.12 and updating the module version constraint in each configuration to refer to the new major version.
30. For a long time, users have wished to be able to use the count meta-argument within module blocks,
allowing multiple instances of the same module to be created more easily.
Again, we have been laying the groundwork for this during Terraform 0.12 development and expect to
complete this work in a later release. Along with count, module blocks will also accept the new for_each
argument described for resources above, with similar results.
This feature is particularly complicated to implement within Terraform's existing architecture, so some more
work will certainly be required before we can support this. To avoid further breaking changes in later
releases, 0.12 will reserve the module input variable names count and for_each in preparation for the
completion of this feature.
33. Terraform 0.12 continues to support the previous splat operator usage in most cases, but does introduce
two important breaking changes.
34. Referencing the resource without an index now results in a list of all of the instances,
rather than behaving as an alias for the first instance. For any resource where count
is set — even if it is set to 1 — the first instance must be accessed by indexing with
[0], such as aws_instance.example[0].id.
35.
36. Early versions of Terraform required splat expressions to appear interpolated into a list constructor, like
["${aws_instance.example.*.id}"], but this requirement was lifted in Terraform 0.9.6 and this form was
deprecated.
In Terraform 0.12, that expression now produces a _list of lists_, since the splat expression produces a list
itself and then the outer brackets wrap that result in another list.
38. In particular, prior to v0.12 the conditional operator works only for primitive types (not lists or maps) and
will always evaluate both value expressions even though only one is ever returned.
Both of these limitations are lifted in Terraform 0.12.
39. Terraform v0.12 now allows assigning the special value null to an argument to mark it as "unset". This can
be combined with other language features so that a module can allow its caller to conditionally override a
value while retaining the default behavior if the value is not defined.
47. References to resources and modules for fields such as depends_on used to be arbitrary strings.
In Terraform 0.12, the resource identifier can be used exactly such as aws_kms_grant.example (no quotes!).
This improves the validation and error messages we can provide. Similarly, a resource reference can be
returned from a module as an output or accepted as a parameter.
48. Want more?
● https://www.hashicorp.com/blog/terraform-0-1-2-preview
● https://learn.hashicorp.com/terraform/
● Opening Keynote Segment: Terraform 0.12, Free SaaS Tier, HCL2 — Paul Hinze, HashiCorp
● Day Two Keynote: Terraform is Changing the World — Paul Hinze, HashiCorp
● A Tour of Terraform 0.12 — Kristin Laemmert, HashiCorp
● 10 Lessons Learned From Writing Over 300,000 Lines of Infrastructure Code — Yevgeniy "Jim"
Brikman, Gruntwork