Remove chef_version user variable & remove Chef installation option.
#362
Conversation
In an effort to simplify the potential for behavior proliferation that user variables allows, the `chef_version` user variable is being dropped. The default behavior was to *not* install Chef for all Bento boxes as downstream tooling such as Test Kitchen or vagrant-omnibus can handle Chef installations at boot time.
|
@yzl, @scotthain: Can either of you foresee the need the preserve the "install Chef" behavior in Bento? |
|
👍 I like the boxes agnostic :) |
| @@ -102,21 +102,18 @@ | |||
| ], | |||
| "post-processors": [ | |||
| { | |||
| "output": "builds/{{.Provider}}/opscode_centos-5.11-i386_chef-{{user `chef_version`}}.box", | |||
| "output": "builds/{{.Provider}}/opscode_centos-5.11-i386.box", | |||
There was a problem hiding this comment.
These kinds of strings are hardcoded here:
https://github.com/test-kitchen/kitchen-vagrant/blob/master/lib/kitchen/driver/vagrant.rb#L112
Needs to still be "_chef-provisionerless.box"
There was a problem hiding this comment.
Ah, that's a good catch. I'm hoping to update kitchen-vagrant just as soon as we can get boxes publishing up to Atlas. That could mean in the very short term that the box would have to be renamed when uploading to the S3 bucket. About 2 PRs down the road, I'm hoping to change the box file names even more so this is going to be important to keep in mind.
|
Yeah 👍, keep these boxes simple and provisonerless. We don't need to spend time supporting chef and puppet and ansible and salt and that entire bikeshed. |
|
👍 I'd rather keep the boxes agnostic. |
Remove `chef_version` user variable & remove Chef installation option.
In an effort to simplify the potential for behavior proliferation that
user variables allows, the
chef_versionuser variable is beingdropped. The default behavior was to not install Chef for all Bento
boxes as downstream tooling such as Test Kitchen or vagrant-omnibus can
handle Chef installations at boot time.