weekly.tf - HashiConf Digital Videos (#14)

The videos from the HashiConf Digital are finally posted somewhere public, so I am going to be working through them and posting a few summaries each week. The whole list is at that link, so if you don't want to wait for me to work through them, have at it.

Beware, if you are expecting this presentation to give you a roadmap or date for a Terraform 1.0 release, you will be disappointed. However you will get something more durably valuable – an insight into the philosophy and thought process behind figuring out when and how 1.0 will be ready.

Kristin describes a planning discussion her team took, starting with the Packer 1.0 blog post and leading to an understanding of a unique HashiCorp philosophy regarding the right framework for applying to deciding if software is "1.0 ready".

Philosophy

While the common definition, as codified by Wikipedia's "The software is feature complete and production ready." would mean that Terraform is more than ready for 1.0, the philosophical standard that this team hold is, quoting–

  1. The project is deployed broadly and has years of production hardening.

  2. Major use cases are understood and well-supported.

  3. User experience of the project is well-defined.

  4. Technical architecture is stable and mature.

Watch the video or read the transcript to get more details on those more philosophical points, which really are great.

Though the more tantalizing part, which folks are are probably going to latch on are the themes of work that could be done for 1.0–

Architecture

Maturity can be improved by doing some internal refactoring work. For example, some refactorings to reduct copy-pasta technical debt, easier test writing and a "gnarly" refactor of the plan-refresh-apply walk of internal data structures with a eye toward future improvements.

Support

Clear support policies and processes - supported platforms and LTS policies need to be updated and communicated to users. And anything that needs to be broken will need to happen before 1.0, otherwise the team will have to live with it until 2.0.

Internal Processes

There is a lot of work to triage, groom and plan the roadmap. Additionally the team is investing in planning out releases and improving the ability to predict releases.

Communication

There is much room to improve communication with the community - milestones, roadmaps, etc.

Possible features

Some likely features–

  • cli vs cloud parity

  • better handling of sensitive values

  • improved importing

  • improved module testing

  • upvoted and often-requested features

0.14

There will be a 0.14 release before 1.0, which is seems will be used to make any final breaking changes before 1.0. Maybe a 0.15 too?

HashiCorp has recently started offering a Terraform Associate certification.

Why would you want to take it? From the panelists–

  • As these tools grow in popularity, especially among large enterprises, certifications will become important for hiring

  • It can actually be a good way to learn about a tool, as it gives a roadmap to the key knowledge need to use it.

If you want to study for it there is a prep guide assembled by one of the panelists but nothing substitutes for hands-on experience.

A wrap-up of the digital conference.

Notable Releases

Note that this release has a deprecation for data-source aws_availability_zones.

blacklisted_names and blacklisted_zone_ids arguments have been deprecated in preference for exclude_names and exclude_zone_ids respectively. (#13771)