- Terraform Weekly
- Posts
- weekly.tf - #28 - Making Provider Development More Accessible
weekly.tf - #28 - Making Provider Development More Accessible
For those of us in the USA, today is election day. If you have not yet and are eligible, please vote.
I had a chance to look at new Terraform provider plugin development tools last week and it brought up a question that I can't seem to find a good answer to:
Where do terraform plugin developers go for help? The forums are pretty noisy, Github issues are only good if you know you are reporting a bug, and are there any other options?
The Terraform team has announced two new projects intended to make make provider development more accessible.
Before we get to those, let's talk a bit about how provider development works today. To build a provider plugin, you write code against the terraform-plugin-sdk, which takes care of interacting with terraform proper, but also includes a bunch of behavior on top of that interface. This approach has worked well for most providers, but there are a few that need more flexibility (like the kubernetes alpha provider).
The two new projects are terraform-plugin-go and terrafom-plugin-mux.
You can think of terraform-plugin-go as the lowest-level interface that a plugin can use. It is essentially a 1:1 mapping of the wire protocol to a go sdk.
On the other hand terraform-plugin-mux is a multi-plexer that allows you to take multiple plugin implementations, based on either terraform-plugin-sdk or terraform-plugin-go and mux them together. You could have some parts of the plugin (resources or data sources) come from each implementation and the mux will unify them into a single interface. This will enable plugin developers who want to incrementally migrate to the lower level interface the ability to do it, well, incrementally.
Both new projects are version 0.1.0, so they are ready for early adopters. If you are a plugin developer, I would suggest taking a look if only to get a sense for where things are going.
This is a terraform newsletter and this article makes a conclusion that they should use CDK. Good food for thought for those of us who stan for terraform.
Notable releases
If you read last week's issue you already saw this, but a all of the "utility" providers, like random, are being updated and no longer support terraform 0.11.
Second beta for 0.14. Note that the changelog is against the 0.13 line, so it is getting quite long already.
Lots of small improvements in this release, nothing super notable.
The AWS API has an enormous surface area and I would content that the terraform aws provider and its docs are the best way to interact with and understand the API.
Case in point, I learned via this release that creating an S3 bucket on an AWS Outpost works differently than in a partition.
I also learned that you can use the AWS storage gateway service to emulate a tape pool. I am not even old enough to have ever worked with tape and I am not young.
Finally this release has a bunch of changes to data source id attributes (example). I honestly don't understand what is going on there, but if that sounds like something you care about, take a look.
A release with 1 bug fix which has no description of the bug.
Bug fixes only, but take a look if you use github draft PRs or have had trouble with required_version support and Terraform 0.13.
Fix for a really interesting bug.
Interesting, I thought that the 'id' attribute of all resources was required, but it appears not.