Chef provisioner?

[btomasini]

Is anyone aware of an existing native chef provisioner for terraform? My initial searches have not turned up anything. I am interested in one, have begun work on an implementation, but would like to avoid duplicating work if one already exists.

[willejs]

@btomasini i would be interested in this, solo, zero & server if possible.

[jperry]

👍

[failshell]

👍

[svanharmelen]

I'm currently finishing up a Chef provisioner implementation. But it's depend on PR #1483 so we first need to get that one up-to-spec so it can be merged, and right after that I'll open a PR for the Chef provisioner.

It's currently a chef-client provisioner meant to work with a chef-server... So maybe it should be called chef-client provisioner so that someone could also create a chef-zero provisioner.

Or the current (well, almost current 😉) provisioner should be extended later on to support both types...

[btomasini]

Very cool. I am going to give it a try. Thanks for putting this together.

I agree that it should be called chef-client.

[svanharmelen]

Maybe you want to wait for another couple of hours as I'm just about to finish this one... The only thing left is setting the inital runlist and attributes.

Small task, but sort of important functionality :) I'll ping you here when I'm done so you can test it. Would be good to have sone feedback...

[svanharmelen]

@bensojona it still needs some tests and docs, but the provisioner should work as you would expect now.

If you don't want to wait and want to play with it, you need to build TF yourself from this branch as all this is not merged into master yet. So be aware that the layout and config options are still very much subjected to change!

[btomasini]

@svanharmelen I tried it out and it works well. I do have some feedback you may want to consider, including some code changes you can pull from https://github.com/btomasini/terraform/tree/f-chef-provisioner

An overview:

• Replaced the download / upload / install process with an execution of the Chef omnibus script. I found this was much faster, especially when connection over my mobile hot spot on the bus. :)
• Related to the change above, removed the required package parameter.
• Implemented "_default" as a default for environment and removed the required parameter.

You will find that my commit removed all of the code which is replaced by the omnibus download. This is not to suggest that it should be removed permanently. It was just dead code and I thought it better to see the full consequence of the change. I am aware that this will not work for Windows and likely breaks other things. So take the changes with a grain of salt and merge what you find useful.

Let me know what you think. Thanks again for all your work on this.

[svanharmelen]

@btomasini thanks for the feedback... I understand your reasoning, but your change effectively removes support for Windows 😉 Next to that it will also kill the use case where your new box doesn't have free/open internet access.

So I don't think this particular change should be used as is, but I see your use case so will see how to build that option in in a more generic way... Thx!

[btomasini]

@svanharmelen I agree. The change really focuses on a more narrow use case - a *nix box attached to the Internet using the omnibus installer. Since I that is perhaps the most common use case for this provisioner, it might be good for that to be the default (?).

It may also be good to use an omnibus type installer for Windows as well, in the same way that knife bootstraps a windows node:

https://github.com/chef/knife-windows/blob/master/lib/chef/knife/bootstrap/windows-chef-client-msi.erb

Ben

[svanharmelen]

Yeah I know how the bootstrap process works, but don't really like it in combination with TF... In the end you are just copying scripts around (or downloading them from the web) so the scripts can figure out which MSI, RPM or DEB to download. So why not just tell what package you want and take it from there? Feels a lot cleaner and the results is exactly the same... Being that a single MSI, RPM or DEB is installed.

The thing I certainly do agree with is speed and easy of deployment, so letting the host download the package could speed up things a lot. And maybe giving the option to use the scripts if you really want to, would also make some people happy, so will have a look at both these topics to see how we can improve on these parts without losing any of the current features.

[CpuID]

+1 to using Omnibus, supporting both paths and making Omnibus the default feels like the sensible option. Omnibus does a lot of OS detection that is almost not worth duplicating, and picks the right package file accordingly.

[svanharmelen]

@btomasini @CpuID just created PR #1868 which contains a reasonably complete and well tested Chef Client provisioner for both Linux and Windows. I listened to both your comments, so I changed and updated the logic with regards to the earlier version you already tested with.

It now mainly uses the omnibus installer for Linux and a custom made omnibus like installer for Windows. So now you only have to specify a version (or leave it out if you just want the latest) and off you go. So if your up to it give it a test drive and see it this makes more sense...

[btomasini]

@svanharmelen Thanks for putting this together. I understand this is already merged to master - very cool! I am looking forward to using it.

[jmreicha]

Would there be any reason to provision a chef node via cloud config now that this has landed? It looks like this will be a much cleaner way.

[svanharmelen]

@jmreicha I think using the Chef provisioner has the advantage that it keeps monitoring the node until the initial Chef run is finished. So it's able to mark a node as tainted when that run failed.

Also being able to save the logs of the initial Chef run locally can be a very handy feature that adds some value.

That being said, both are valid solutions of course so it also comes down to your use case and personal preference I think.

[jmreicha]

@svanharmelen thanks 👍

[dupuy]

@jmreicha see my feature request #2010 - from a pragmatic perspective using this provisioner will be more functional for the reasons @svanharmelen suggests; but a cloud-config registration might be able to leverage a (future, still unwritten) Chef provider for some of the status tracking / tainting etc.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.