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
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.
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.
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.
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.
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.
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.
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.
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.
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
rkaga
siroemk
palkan
optim
akihisaikeda
utakaha
shihochan
gam0022
timakin
econanringo
ichirokano2
kishida
marcelosomers
vanstee
seathinner
tapps
garrettdimon
szymonslowik
akademiya2063
cassininazir
jeffersonlam
aarron
badams
sergeychernyshev
