Vagrant destroy should remove client and node from chef server

[oliver-dungey]

When you use vagrant with Chef the first run of chef-client will register a new client and node with the chef server. When you issue a vagrant destroy command it does not delete the chef client and node. As a result developers find themselves continually bumping into the error "409: conflict, client already exists" every time they destroy a vagrant instance and this leads to wasted time. A great enhancement to vagrant would be to add some code to the destroy command would be the removal of the corresponding client and node from the chef server - this would allow people to repeatedly up/destroy images without the need for manual interaction each time.

[mitchellh]

I agree, this needs to be a feature in Vagrant. Marked as a feature, no milestone yet.

[yfeldblum]

In the meantime, add to the docs:

$ knife client delete #{fqdn} --yes
$ knife node delete #{fqdn} --yes

[skippy]

something like so? https://gist.github.com/1010660

[oliver-dungey]

Nice one skippy

[mitchellh]

Skippy, thanks for that. I plan on implementing something like that into Vagrant as a full on feature. I'll use that as inspiration.

[mitchellh]

Hello all,

I've been thinking and working on this and I've ran into quite a few user-experience issues.

• The easiest way to do this would be to use the Chef installation already in the VM to remove the node and such. However, during a destroy, if the node is already down, then SSH is not available. Requiring a VM to be up to destroy is not acceptable.
• Using local knife from the Chef provisioner is another option, but requires knife to be installed. knife must also already be setup as a client of the Chef server, which it isn't by default. This may surprise people. An option is to make this feature an option which is disabled by default and only enable it via a provisioner option.
• Vagrant can't use the Chef API directly because the computer might not be setup as a client and doing all that just to remove another node is often defeating the purpose and is also very complicated.

I do believe this is an important feature, but the complexity is rather high. Continuing with the plugin approach for users who need this may be the best approach. I'd like feedback.

Thoughts?

[yfeldblum]

With #3, ask the user for his credentials (username & private key file) on the chef-server.

[mitchellh]

I've decided to actually leave this up to the user for now, due to a lack of good libraries for Chef.

[gmacid]

Just commenting on the original issue (as I just had it and decided to solve it like this)

I don't think extra features in vagrant are necessary with the following configuration:

client_key_path = "/certificates"

config.vm.define :some_node do |node_config|
node_config.vm.provision :chef_client do |chef|
chef.node_name = "some_node.local.net"
chef.client_key_path = "#{client_key_path}/some_node.pem"
end
app_config.vm.share_folder("certs", "#{client_key_path}", "./certificates", :owner => "root", :group => "root")

(Assuming you have a .gitignored writable certificates directory local to your Vagrantfile)

This way, the first time you generate, it will register under a different node name (than the traditional published vagrant-distribution.vagrantup.com image node name), and store the cert in a shared folder, which next time you down/up it, will have access to its certificate.

I would suggest being able to passthrough the client.pem as well as the validation.pem from host to guest as a way to solve it otherwise.