chef_client provisioner fails to cleanup node on chef server #2476
Comments
|
The first issue you saw should be fixed. The second is a bit more involved... I've tagged this as a bug. |
|
I have the same issue with latest 1.4.0: |
|
Both stack traces include RVM ruby and Vagrant's embedded ruby libraries/gems. Feels like Vagrant sets the gem environment so that when it executes |
|
A dirty workaround that might work would be to install chef to Vagrant's gem/plugin store. Something like: Note that it probably gets uninstalled with next |
|
Thanks @tmatilai I got around the gem issue, but the node/client stay on the Chef server unfortunately. I have |
|
@scalp42 Could you run with |
|
My node/client name is The knife commands run fine and delete the node: My config.vm.define :zs1 do |zs|
zs.vm.hostname = 'zs-common-scalp-vagrant-vbox'
zs.vm.provision :chef_client do |chef|
chef.chef_server_url = ENV['KNIFE_CHEF_SERVER']
chef.validation_client_name = ENV['KNIFE_VALIDATION_CLIENT_NAME']
chef.validation_key_path = ENV['KNIFE_VALIDATION_CLIENT_KEY']
chef.log_level = 'info'
chef.node_name = 'zs-common-scalp-vagrant-vbox'
end
endHere the gist on |
|
@scalp42 You need to explicitly enable Chef client and node deletion: chef.delete_client = true
chef.delete_node = true |
|
Derp. Sorry reverted my changes. Let me re-add it. |
|
Btw, this seems to be totally undocumented feature. I'll offer a 🍌 for a PR! Anyone? |
|
@tmatilai Keep it undocumented because it doesn't work at the moment due to various path issues... hence the issue. :( |
|
@mitchellh Ah, gotcha. I don't use the chef-client provider so I had no idea of its state. Just remember when it was mentioned in some release notes. |
|
opened this, feel free to close it #2627 |
|
Thanks! |
|
The behavior I was seeing was with vagrant-aws actually not cleaning up if on EC2. Will open a issue there mitchellh/vagrant-aws#170 |
|
I too hit this snag, trying to use vagrant with chef.delete_node ... The above hack works, but it hardly looks like the correct fix. My host machine is using RVM ... |
|
For working around this issue I patch the chef_client provisioner to force knife to use them correct GEM_PATH, but it's hardly a fix: diff --git a/plugins/provisioners/chef/provisioner/chef_client.rb b/plugins/provisioners/chef/provisioner/chef_client.rb
index 30913b0..b894f84 100644
--- a/plugins/provisioners/chef/provisioner/chef_client.rb
+++ b/plugins/provisioners/chef/provisioner/chef_client.rb
@@ -118,7 +118,7 @@ module VagrantPlugins
deletable: deletable, name: node_name))
command = ["knife", deletable, "delete", "--yes", node_name]
- r = Vagrant::Util::Subprocess.execute(*command)
+ r = Vagrant::Util::Subprocess.execute(*command, {:env => {'GEM_PATH' => '/Users/pedro/.rvm/gems/ruby-1.9.3-p448:/Users/pedro/.rvm/gems/ruby-1.9.3-p448@global'}})
if r.exit_code != 0
@machine.env.ui.error(I18n.t(
"vagrant.chef_client_cleanup_failed",
If only the original GEM_PATH was exposed to plugins, this would be a lot cleaner. Maybe by creating a new environment variable |
|
Still getting the same error with Vagrant 1.4.3 (running on windows 7). Is the work around ^ the only "fix" for now? |
|
I have the same issue and could get it running with the workaround mentioned by @tmatilai. |
|
Fyi, last night I spiked to replace the current shell-out implementation with using ChefAPI gem and stealing ideas from vagrant-butcher. It looks promising, and I try to get a preliminary PR out soon. |
|
I have identical error to ostap36, running Vagrant 1.4.3 on Windows 8.1. I tried the workaround but it didnt work. |
|
+1 on fixing this |
|
Still having this problem with 1.5.2 on Ubuntu 12.04 x86_64, but the error for me looks a bit different than the above: |
|
Same here with 1.5.2 on Mavericks |
|
+1 Hope to see a fix. The fix from @tmatilai did not work for me: Deleting client "mynode" from Chef server... stdout: stderr: /Applications/Vagrant/embedded/gems/gems/bundler-1.5.3/lib/bundler/spec_set.rb:92:in |
|
Has anyone discovered a workaround for Ubuntu Users? I tried the following /opt/vagrant/embedded/bin/gem install --no-ri --no-rdoc --install-dir ~/.vagrant.d/gems chefhowever, I still seem to be having the same problem Any suggestions would be appreciated! |
|
I was having the same issue - I installed the vagrant-butcher plugin and was able to work around the problem (https://github.com/cassianoleal/vagrant-butcher/). I've temporarily disabled the chef.delete_client and chef.delete_node properties until a stable fix is released. |
|
any update on this issue ? is it gonna be fixed or do we need to use workarounds? |
|
@mitchellh are we sure this is related to the provisioner? I get a very similar error with puppet and the r10k-vagrant plugin and rbenv on a mac. I've posted a full debug output to the vagrant plugin developer who seems fairly stumped: jantman/vagrant-r10k#2 |
|
@fpletz the issue is generally "shelling out from one Ruby environment into another Ruby environment is almost 100% impossible", so yes, puppet would be affected as well if you have puppet installed like that. |
|
@sethvargo As a bystander, I'm curious - WHICH Gemfile would need updated to resolve the issue? |
|
@rnelson0 it's not a Gemfile issue, but a "shelling out" issue. Some people are using Ruby versions managers (like rbenv, chruby), which mangle themselves into the $PATH when a new shell is spawned. We can unset all the bundler-environment variables we want, but that's not going to fix this issue sadly 😦. |
|
Wouldn't saving the original GEMPATH on a global variable and have that available for the shell out work? (as I suggested on #2476 (comment)) |
|
@pharaujo no, because Vagrant runs in an entirely different Ruby than these other gemsets |
|
@sethvargo I know, but that should be irrelevant for the shell out. The problem here is that the GEMPATH set by Vagrant - which contains the embedded gems - does not have knife or its required dependencies and so it fails. If you make available the system GEMPATH to the Vagrant plugins, they can use that in their shell outs. Vagrant::Util::Subprocess.execute(*command, {:env => { 'GEM_PATH' => ORIGINAL_GEM_PATH }}) |
|
Just for clarity sake, running OS X 10.10's system ruby yields the same error. Gist found here: https://gist.github.com/4c8c7cb523eeda3f9816 |
|
I think, for once and for all, this is fixed by #5912 😄. Unfortunately this is a generally unsolved problem and each Ruby version manager behaves slightly differently. With the complex behavior of Bundler, individual system settings, and star/moon alignment, it is possible that whatever incantation of Ruby + Chef + other rubies on the system that this might still persist for a small number of users. We have chosen to optimize and test for the "common" use case, which is ChefDK, using Vagrant in the official installer and using Vagrant as a bundled gem. I also tested rbenv and chruby (for the Chef installation) and was able to get things working. I am marking this issue as fixed, while recognizing that certain situations may not be accounted for. Unfortunately we just can't make this work perfectly for everyone. If you are experiencing issues, please open a new issue and include your Ruby setup, Chef installation, Vagrant version, and the debug output. Moving forward, we will likely only support bug reports as they relate to the official installation processes for both tools (ChefDK and Vagrant's official installer). This will be released in Vagrant 1.7.3 |
I am having trouble cleaning up the node on chef server when destroying a vagrant instance.
My config:
Destroying gives a stack trace:
I had a look at the source code and it seems
node_nameis not defined, so I added the following to my config:This almost worked, but it seems knife tries to use the embedded GEM_PATH and fails to load its core dependencies:
The text was updated successfully, but these errors were encountered: