[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Delete node and client when destroying Vagrant VM

[Joshua Timberman < >]

Back in March, I wrote about a multi-vm vagrantfile I use for testing[0].
One of the commenters posted a snippet to add at the very end of the file
to automatically cleanup. As a disqus comment, it didn't format well, but
I posted it here. Thanks, Eric Edgar for this!

https://gist.github.com/38ad69522a8eeb5f52be



-joshua

[0]: 
http://jtimberman.housepub.org/blog/2012/03/18/multivm-vagrantfile-for-chef
/




On 12/9/12 9:35 PM, "Juanje Ojeda Croissier" 
<
 >
wrote:

>I believe Mitchell has closed, time ago, a similar issue:
>https://github.com/mitchellh/vagrant/issues/336#issuecomment-3100510
>
>Here some of the reasons he gave:
>"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.
>"
>
>On Sun, Dec 9, 2012 at 6:26 PM, Cassiano Leal 
><
 >
>wrote:
>> I created pull requests on the Vagrant issue
>> (https://github.com/mitchellh/vagrant/issues/1253). Chime in with your
>> opinions and comments!
>>
>> --
>> Cassiano Leal
>>
>> On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:
>>
>> https://github.com/mitchellh/vagrant/issues/1253
>>
>> I wonder if we can close the one in Berkshelf.
>>
>> --
>> Cassiano Leal
>>
>> On Saturday, December 8, 2012 at 16:08, Jamie Winsor wrote:
>>
>> It probably is more appropriate to put it into Vagrant's chef_client
>> provisioner
>>
>> --
>> Jamie Winsor
>> @resetexistence
>> https://github.com/reset
>>
>> On Saturday, December 8, 2012 at 7:16 AM, Cassiano Leal wrote:
>>
>> I see that you opened that ticket on Berkshelf, but wouldn't it make
>>more
>> sense if Vagrant's chef_client provisioner would do that job instead?
>>After
>> all, it's Vagrant who creates the client and node in the Chef server.
>>
>> --
>> Cassiano Leal
>>
>> On Friday, December 7, 2012 at 22:58, Jamie Winsor wrote:
>>
>> Here is the ticket: https://github.com/RiotGames/berkshelf/issues/264
>>
>> --
>> Jamie Winsor
>> @resetexistence
>> https://github.com/reset
>>
>> On Friday, December 7, 2012 at 3:48 PM, Cassiano Leal wrote:
>>
>> Wow, thanks for the enlightening answer Daniel, that's exactly the sort
>>of
>> thing I wanted to understand. I'll study both approaches before I decide
>> which one to go with.
>>
>> Jamie: Ridley looks great, thanks for writing that. Also yeah, I'm using
>> Berkshelf, and having that sort of functionality built into Vagrant
>>would be
>> fantastic. Let me know the ticket number when you create it so that I
>>can
>> chime in, if you don't mind!
>>
>> Adam: that comment made my afternoon! :)
>>
>> Cheers guys!
>> --
>> Cassiano Leal
>>
>> On Friday, December 7, 2012 at 18:24, Daniel DeLeo wrote:
>>
>>
>> On Friday, December 7, 2012 at 11:29 AM, Adam Jacob wrote:
>>
>> Use the REST api like a boss, man. That's what it is there for.
>>
>> Adam
>>
>>
>>
>> On 12/7/12 10:17 AM, "Cassiano Leal" 
>> <
 >
>>  wrote:
>>
>> It would be nice to know the reasoning behind not using the REST client.
>>
>>
>>
>> The higher up the chain you go, the more places we have to hide changes
>>from
>> you. For example, we'd like to some day remove the json_class stuff
>>from the
>> API, which means that the data you get back from Chef::REST will
>>probably be
>> a Hash instead of a Chef::Node (or whatever you asked for). If
>>(continuing
>> the example) you use the methods on Chef::Node, you wouldn't be
>>impacted by
>> this. Contrarily, the higher up the chain you go, there's more things
>>that
>> could be changed. As a concrete example, the #save method is defined on
>>all
>> of the model classes to try to update and then fall back to create (or
>>vice
>> versa, it's not 100% consistent). We'd like to change this at some
>>point so
>> there are separate create and update methods since 99% of the time you
>>know
>> which one you need.
>>
>> Either way, changes to the API or to core model class functionality are
>> generally only going to be shipped with major releases (e.g., 10.x ->
>>11.x)
>> and we'll do our best to document them and announce them ahead of time
>>on
>> this mailing list (upcoming changes in Chef 11, for example:
>> http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11 ;).
>>
>> In conclusion, there are trade-offs either way, but both ways are valid.