Skip to content

Instantly share code, notes, and snippets.

@randomcamel
Forked from mitchellh/response.md
Created March 20, 2019 16:37
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save randomcamel/5f31da5db295ecdad75024d594a90b1f to your computer and use it in GitHub Desktop.
Save randomcamel/5f31da5db295ecdad75024d594a90b1f to your computer and use it in GitHub Desktop.

This is a bit of history and a bit of a quirk in timing...

The history first...

Vagrant has all manner of provisioners effectively supporting any CM tool as well as supporting plugins to add more. When I started on Packer, I basically copied this model (nit: provisioners aren't pluggable anymore cause no one ever used that functionality but the interfaces are very similar and Packer also supports all manner of CM tool).

An issue that beleaguered Vagrant and subsequently Packer is that these CM tools were fast moving, they had many versions that were popular at the same time, and there are a lot of "mini" ones or newcomers. This leads to a few problems:

  1. The integrations are often very version specific and contain a lot of complex logic version-checking the CM tool to do the right thing. This is really difficult to maintain.

  2. Only one CM vendor (won't name) stepped up during Vagrant to maintain their provisioner. That's okay, but the problem that causes is that it falls down to maintainers to maintain the CM integrations and they may not use them anymore or may not be familiar with them. This leads to bugs that don't get fixed and overall poor show.

  3. There are a lot of small or newcomer provisioners. They often make PRs to support their provisioners. The problem here is given #1/#2 above: if we accept the PR, we're on the line generally for fixing bugs. And the other issue is: how do we say no? "You're not popular enough" while true is mostly subjective and hurts to say. It also can cause some drama.

So then Terraform came along...

And we decided that the only provisioners would be: local-exec, remote-exec, and file (for uploading). This is awesome because you can do literally anything with these three. You can run Chef remotely, you can run Ansible locally, you can do some local shell scripts prior to running Puppet remotely, you can run a CM tool I've never heard of, etc. etc.

And it was great. Users loved it.

Then we started getting requests: "but where is X?" And we'd explain "look! you can do anything with these building blocks!" but then we learned that there is a large group of users that do not want building blocks. They want to say "here is my recipe make it happen."

And for a long time we said no. And virtual pitchforks were risen, issues were open, tweets were tweeted, and much bashing was had that "Terraform doesn't support Chef!" (or whathaveyou). Even though, we support literally anything because we have the primitives to do literally anything. But anyways...

A user came along and opened a high quality PR to add a Chef provisioner to Terraform. This led to much discussion internally and in the issue. We ultimately yielded, pressured into it.

And it has had all the same problems Packer and Vagrant had. 😓

Then more provisioners appeared...

The slippery slope had been well greased.

Soon provisioner PRs began showing up. But we recognized we'd made a huge mistake because we made the same mistake that Vagrant and Packer made.

In the mean time, the company had grown and we had learned to work with dozens of vendors to work together to build functionality via Terraform Providers. The Terraform Provider development program had been so successful we thought "hey, we should do this with provisioners." That way we don't have to remove them, our gate to supporting them would be a promise of maintainership and quality, and we can support more! Hurray!

Simultaneously and coincidentally, we embarked on a huge, complex, but wonderful journey that is Terraform 0.12. And this was changing all sorts of plugin interfaces. So we decided to NOT embark on this provisioner-as-plugin journey until 0.12 was completed.

We also decided NOT to merge any more provisioners until 0.12 core stabilized, they could be rebased, and we had communicated with the contributor or vendor to ensure they'd stay on to maintain it.

And that leads us to where we are today.

So Chef is in there because of some luck with timing. The others aren't there because historically we just didn't think high-level integrations were necessary at all. And the others are now not coming in (even with PRs) because they're blocked on 0.12 (and our alliances team is also not focusing on them because of this).

The story is always more complex than it seems! 🤫

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment