Closed phs closed 8 years ago
Hi @phs
Thank you for opening an issue. I am okay with allowing users to install chef-dk instead of chef. However, I do not think that the Berksfile is going to remain the canonical source for cookbooks and therefore it should be up to the user to install those cookbooks; there are just too many edge cases and customizations that a user might like; it's better solved via a shell script. Additionally, I think Chef is working on Policyfile things that will eventually replace the Berksfile.
If berks' place in the ecosystem is or will be unstable, would you consider including the berks functionality here if its surface area was reduced and it were strictly opt-in? Perhaps the new options concretely appear as
config.vm.provision :chef_zero do |chef_zero|
# Chef package to install, default 'chef'
chef_zero.package = 'chefdk'
# Where's the Berksfile? The default is no Berksfile. If set, the provisioner will try
# to install berks dependencies. If set, it is an error for the file to be missing or
# berks to not be found in binary_path.
chef_zero.berksfile = 'Berksfile'
end
@phs
No, I'm sorry. I'm one of the core authors of Berksfile. I love the tool :smile:. But I don't think it's Vagrant's responsibility to push that tool onto users until Chef Software makes a decision about where the tool stands in their ecosystem.
Right now, if I simultaneously want to use vagrant as my app's dev environment and chef as my provisioning tool, then I need a way to run chef in the guest. Presto, the
chef_zero
provisioner comes to the rescue and all is well.If, following the example of virtually all chef-provisioned services, I need to also install berks dependencies, I am suddenly up a creek without a paddle.
Why is that?
There is vagrant-berkshelf which at least at one point was the canonical answer to this need, but it has a problematic history. The show-stopping bug for me currently is the inability of my host ruby and guest ruby (embedded in chef) to coexist. The issues listing over there is littered with various permutations of this core problem. Apparently it is so bad that the plugin itself is being phased out.
That's unfortunate, but fine as far as it goes. I should just move onto the next thing. Except @sethvargo over here is telling me in that post that the next thing is to ditch vagrant and do everything in kitchen. (Am I actually reading that right?)
That is not fine.
Surely something can be done.
Since the core pain point is the dueling rubies, one's forced to ask why we need to have them both. "Well, berks isn't installed on the guest, but we know it's on the host since we force you to install the tool chain on the host OS. So we need the host ruby."
Why can't we have berks in the guest? If I'm willing to have chef installed within my guest to run the provisioner, I may well be willing to have chefdk. Then I (or rather, the provisioner) can use the full tool chain without any need for extra plugins (or extra host OS dependencies!)
It took me about 20 minutes to blast this out and see it work:
In
Vagrantfile
:In
scripts/bootstrap-vagrant
:This yields a vagrant provisioned by my cookbook, dependencies and all, with a guest-only toolchain.
So, my proposal is some new "common" options for the chef provisioners that lets users opt-in to installing chefdk instead of just chef.
Following vagrant-berkshelf's behavior (and if the user chose to use chefdk), if a
Berksfile
is found or declared by the user, an appropriate berks call is made to install dependencies in the guest where they need to go before firing up chef-client.Concretely the new options might look like this: