Upcoming Provider Changes in Terraform 0.10
Since 2014, Terraform provider growth has been explosive. At Terraform's initial launch, there were less than ten providers. Today, there are nearly 70 builtin providers that ship with Terraform and countless more are distributed as plugins by the community. Community is and will continue to be the core of Terraform's adoption and success.
Currently all builtin providers are distributed as part of the main Terraform binary. As an unintended side-effect, small bug fixes, new features, or security releases for a single provider are blocked until the next release of the main Terraform binary for distribution. About a year ago, Terraform adopted a two-week cadence for releases to rapidly deliver updates and fixes to users, but even this cycle proved to be too long. As upstream providers add new APIs, features, and improvements, Terraform users want to leverage those new technologies as soon as they reach stability. To that end, we are excited to announce upcoming changes to the provider ecosystem in Terraform 0.10 – individually distributed provider plugins.
The goal of separating providers into separate GitHub repositories and deliverable binaries is to increase the velocity of Terraform improvements by giving more ownership and contribution access to more community members.
The Split
Each provider's source now lives independently in its own repository in the Terraform Providers GitHub organization. The split of individual providers from Terraform core enables each provider to define its own release cadence, versioning, and documentation.
Provider plugins are no longer included with the main Terraform binary distribution. Instead, they are distributed separately and are fetched and installed on-demand by the terraform init command. This new approach allows users to upgrade individual providers, use custom or patched providers, and remove providers in isolation. It also decreases the size of the initial package distribution, since Terraform will only download the providers it needs.
Since provider plugins are versioned separately from Terraform itself, individual version constraints allow users to restrict against upstream breaking changes. Just like git init, terraform init will become a key part of the daily Terraform workflow. The prior mechanisms for installing third-party providers will continue to be supported. Maintainers of third-party providers may optionally make use of the new versioning mechanism by following the upgrade process which will be made available shortly.
This new structure also gives more ownership to community members. Previously anyone with commit access to a provider also had commit access to all of Terraform, which led us to keep the contributor pool small. Under this new model, each provider has its own permissions, and repository owners are empowered to control access to their code without granting them access to all of Terraform. This will empower more owners and contributors across more providers.
The core of Terraform will still live at the hashicorp/terraform GitHub repository and will be maintained by HashiCorp employees and trusted external contributors.
The Migration
A project re-organization of this magnitude is not without disruption. We have done our best to make this migration as seamless as possible, but there are always unplanned edge cases.
- Each provider retained full commit history in their new repository
- Original committers still receive credit that they have contributed to Terraform
- Provider-specific issues will migrate to providers (core issues will remain in Terraform core)
Due to the nature of the provider split, Pull Requests will not migrate. Over time, we will do our best to work with pull request authors to migrate their change requests to the provider repositories. We ask that any future community contributions or issues are made against the new provider repositories.
In order to minimize disruption, there will not be another release in the 0.9 series. Instead, the next release of Terraform will be 0.10.0-beta to help smooth out this new process. We realize this provider migration may cause disruption for some users in the short-term, but we're confident the change is in the best long-term interests to maintain the velocity of Terraform's improvements. The Terraform team will be extra active and responsive on the Terraform mailing list these next few weeks to ensure the transition is as smooth as possible. Please let us know if you have any concerns.
Thank You
Thank you to everyone who has helped to make Terraform the leading tool for managing infrastructure as code. Whether you fixed a typo, resolved a bug, wrote a provider, or built the graph engine, you and the contributions of 1,105 others have played a key role in the success of the project. Thank you for giving us the opportunity to work with you, and we look forward to what we can continue to build together.
Sign up for the latest HashiCorp news
More blog posts like this one
Terraform delivers launch-day support for Amazon S3 Tables, EKS Hybrid Nodes, and more at re:Invent
The Terraform provider for AWS now enables users to manage a variety of new services just announced at re:Invent.
HashiCorp at re:Invent 2024: Infrastructure Lifecycle Management with AWS
A recap of HashiCorp infrastructure news and developments on AWS from the past year, from a new provider launch to simplifying infrastructure provisioning and more.
Simplify policy adoption in Terraform with pre-written Sentinel policies for AWS
HashiCorp introduces a new pre-written policy library co-developed with AWS, aiming to reduce the barrier of adoption for policy as code infrastructure workflows.