vagrant chef_zero complain about missing required value for 'chef.nodes_path'

[wilddog64]

I am using vagrant 1.8.1, and when I use chef_zero as a provisioner, it reports the following error message:

There are errors in the configuration of this machine. Please fix
the following errors and try again:

chef zero provisioner:

• Missing required value for `chef.nodes_path'.

Here's vagrant debug output. I notice this happen before, but seems like it come back again, and here's Vagrantfile.

Currently, vagrant has these plugins,

vagrant-aws (0.7.0)
vagrant-awsinfo (0.0.8)
vagrant-berkshelf (4.1.0)
vagrant-share (1.1.5, system)

However, if I switch to use chef_solo, everything will just work fine

[wilddog64]

This problem seems also affect vagrant-aws provider. If the Vagrantfile is configure to use aws as a provider, both chef-client and chef-solo failed

[mcpierce]

I'm experiencing this same problem. But I'm not using AWS. Instead we have a local vmware_fusion provider. The only plugins we're using are:

• vagrant-proxyconf
• vagrant-berkshelf
• vagrant-vbguest

[bdwyertech]

When's the last time y'all ran vagrant plugin update? That's really weird with chef-solo

FYI, if you read the chef-zero provisioner documentation, it states that nodes_path is required.
https://github.com/mitchellh/vagrant/blob/master/website/source/docs/provisioning/chef_zero.html.md
https://git.io/vzAzW

[jeremydyoung]

The chef.nodes_path has been on a little roller coaster over the last several releases. Release 1.7.3 caused chef.nodes_path to be unavailable (#5339), and then 1.8.0 restored it to functional (#6025), but also made it required.

I am not 100% sure why chef.nodes_path is now a required attribute, but if your team is using both vagrant 1.7.4 and 1.8.1, it is impossible to make a Vagrantfile that uses chef zero and works with both.

Is there any chance the attribute could be made optional again?

[wilddog64]

For now, I switch to use kitchen as my test driven development tool. They do the same thing, but kitchen is a bit more stable at this point. The kitchen I use is coming from chef-dk (0.10.0). Don't use 0.11.0-1 as it has different problem. I am wondering when can we have a next release of vagrant with this problem fix?

[jeremydyoung]

I have recommended to my team that they stay with Vagrant 1.7.4 so we don't have to add the chef.nodes_path attribute in hopes that this will have a better workaround in a later Vagrant.

[sethvargo]

Hi all,

Thank you for opening an issue and for the detailed conversation. You can read more about why the nodes_path is a required attribute in this issue: https://github.com/mitchellh/vagrant/issues/6972. Unfortunately we will not be reverting this change, since having a "node" is a crucial component of working with Chef Zero. You can also find the original issue which influenced our decision to make it required here: https://github.com/mitchellh/vagrant/issues/6110. Thanks! :smile:

[jeremydyoung]

What is supposed to be in this nodes_path directory, and why do I need it? Is it supposed to contain something that I am maintaining about something? Basically it seems like all I have to do is try to figure out a folder that will exist and be empty on all my different developers' machines, whether they are a windows user or mac user.

I've read the recommended github issues, but I still don't see why Vagrant cannot pick and generate a temp folder to utilize for this.

For clarification we use the vagrant-berkshelf plugin, which someone claims is "horribly broken". On Vagrant 1.7.4, everything works well enough for our purposes, which is to bring up in vagrant an application in a way that is similar enough to the way our app servers get configured with our hosted chef.

Is setting a nodes_path something that vagrant-berkshelf should be doing for us? What's so broken about the vagrant-berkshelf plugin?

[mattdeboard]

@sethvargo Please stop introducing breaking changes between minor versions. If you absolutely must because it's a seriously dire need, then you need to issue deprecation warnings.

One of the majorly awesome things about Vagrant _used to be_ that you could just tell teammates to "install vbox, then vagrant, then just run vagrant up, it's easy!" Now I have to go find a specific version that "worked on my machine!" and point them at that, then babysit their installation to make sure there are no more surprises.

Again: please stop introducing breaking changes between minor versions. If you absolutely must because it's a seriously dire need, then you need to issue deprecation warnings. I'll be sticking with 1.7.4 until I can coordinate upgrades for all the members of my distributed team and figure out what the hell value I'm supposed to put in nodes_path.

[mattdeboard]

@sethvargo From Vagrant's own docs:

Any backwards incompatibilities within 1.x will be clearly documented.

There is no "clear documentation" of the addition of nodes_path _as a breaking change_. The fact my entire team, and apparently @jeremydyoung's, have all been using Vagrant 1.7.4 and chef-zero provisioner without specifying nodes_path makes your explanation ring a little hollow.

[sethvargo]

Hi @mattdeboard

Thank you for your comment, and I'm sorry this is causing you pain. I can tell you're frustrated, and it was certainly not our intention to do that. I'm sorry :frowning:.

The "breaking change" was actually in response to a bug fix (https://github.com/mitchellh/vagrant/issues/6025, https://github.com/mitchellh/vagrant/pull/6049, https://github.com/mitchellh/vagrant/issues/6110, https://github.com/mitchellh/vagrant/pull/6559) in the fact that the Chef Zero provisioner in Vagrant _was a lie_ and wasn't actually using Chef Zero. It was chef-solo -z, not chef-client -z. For 99% of users, this was not the desired behavior because solo and client behave differently. This caused a lot of pain for users, so we fixed that behavior. In hindsight, it seems like a small percentage of users were depending on the broken behavior, and I'm very sorry this bug fix broke those use cases.

You don't have to put any values in nodes_path; it just needs to point to a local folder which can mount in the VM. That folder can be empty, but it has to exist because it's where Chef Zero is going to write data (for certain queries) and where it's going to load it's initial data set for nodes (for users who are utilizing search for example). One could argue that Vagrant _could_ automatically create this folder for you, but for some reason that wasn't working (I don't remember why offhand, perhaps a bug in Chef(Zero)).

Finally, I do want to add that Vagrant and most HashiCorp products do not follow semver. Major, minor, and patch releases often contain new features, bug fixes, patches, and more. We didn't consider this a bc-incompatible change because, of the users who were experiencing issues with the Chef Zero provisioner, all had set their nodes_path to contain values or an empty folder because the _chef-zero provisioner requires it_.

Again, I really want to apologize that this is causing you trouble, since that's certainly never our intention. Thank you for understanding, and I hope you have a great day! :smile:

[mattdeboard]

Thank you for the detailed answer.

[Raboo]

Okay I know this is closed.
But very simple solution would be if you add a check that if chef.nodes_path is not specified. Vagrant could create a empty temp folder and internally specify chef.nodes_path to that empty temp folder.
That way you would have support for it and not breaking compatibility with older Vagrantfile recipes.