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

[Erik Hollensbe < >]

Throw a templated script in /etc/rc0.d (or your favorite equivalent that runs in runlevel 0, which is the important part) that looks something like this:

/path/to/knife node delete <%= node.name %> -y -c /etc/chef/client.rb

/path/to/knife client delete <%= node.name %> -y -c /etc/chef/client.rb

Easy recipe to write and no patches required. I do this in AWS autoscaling groups to keep my host chef costs down -- it works.

-Erik

On Dec 10, 2012, at 2:20 AM, Cassiano Leal < "> > wrote:

Interesting thoughts.

The way I implemented it requires knife to be configured in the host, or at least a knife.rb pointing to the chef server and the client key (and probably client name as well). By default it looks for knife.rb in ~/.chef/knife.rb, but that can be overridden in the provisioner. Options could be added for those to be defined in the Vagrantfile itselfas an alternative for a full-on knife.rb.

The whole thing could be made optional, but I don't think it's necessary since all it does when it fails is to throw a warning and carry on. The implementation is not complicated at all and works pretty well. You can check the code in the pull requests I made.

-- 

Cassiano Leal

On Monday, December 10, 2012 at 02:35, 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.

--

Daniel DeLeo

--

Juanje

http://about.me/juanje