Delete node and client when destroying Vagrant VM

Cassiano_Leal · December 6, 2012, 12:03pm

I was trying to find a solution for that on the web, and the two references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/

gist.github.com

https://gist.github.com/skippy/1010660

middleware.rb

class OnDestroyMiddleware
  def initialize(app, env)
    @app = app
  end
    
  def call(env)
    env["config"].vm.provisioners.each do |provisioner|
      env.ui.info "Attempting to remove client #{provisioner.config.node_name}"
      `knife client show #{provisioner.config.node_name}`
      if $?.to_i == 0

This file has been truncated. show original

Neither worked out of the box, so I hacked my own solution, adapting a bit from each, and came to this:

gist.github.com

https://gist.github.com/skippy/1010660

middleware.rb

class OnDestroyMiddleware
  def initialize(app, env)
    @app = app
  end
    
  def call(env)
    env["config"].vm.provisioners.each do |provisioner|
      env.ui.info "Attempting to remove client #{provisioner.config.node_name}"
      `knife client show #{provisioner.config.node_name}`
      if $?.to_i == 0

This file has been truncated. show original

Feel free to use it if you find it useful. Comments and suggestions are welcome.

Cheers!

Cassiano Leal

Jesse_Nelson · December 6, 2012, 2:04pm

You can check out the code in my chef-sandbox that does this using the
vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

Change:

::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef', 'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal cassianoleal@gmail.comwrote:

I was trying to find a solution for that on the web, and the two
references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a bit
from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are
welcome.

Cheers!

Cassiano Leal

Jesse_Nelson · December 6, 2012, 2:04pm

meant to say "no subshell" not "syscall"

On Thu, Dec 6, 2012 at 11:04 PM, Jesse Nelson spheromak@gmail.com wrote:

You can check out the code in my chef-sandbox that does this using the
vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

Change:

::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef', 'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal cassianoleal@gmail.comwrote:

I was trying to find a solution for that on the web, and the two
references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a
bit from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are
welcome.

Cheers!

Cassiano Leal

Cassiano_Leal · December 6, 2012, 3:48pm

Nice one.

Just one correction to my original post, the link to my gist is Vagrant delete Chef node and Client on destroy · GitHub and not the one I sent before (that was a reference).

I like your REST approach, though, and will certainly have a look at that.

Thanks,

Cassiano Leal

On Thursday, December 6, 2012 at 12:04, Jesse Nelson wrote:

meant to say "no subshell" not "syscall"

On Thu, Dec 6, 2012 at 11:04 PM, Jesse Nelson <spheromak@gmail.com (mailto:spheromak@gmail.com)> wrote:

You can check out the code in my chef-sandbox that does this using the vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

Change:
::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef', 'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

I was trying to find a solution for that on the web, and the two references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a bit from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are welcome.

Cheers!

Cassiano Leal

steve · December 7, 2012, 5:58pm

I seem to recall someone from Opscode steering people away from making
direct calls using Chef's internal REST client for some reason. I'd do it
through the Knife object, something like (untested code alert):

Chef::ClientDelete.run(env[:vm].config.vm.host_name)

On Thu, Dec 6, 2012 at 7:48 AM, Cassiano Leal cassianoleal@gmail.comwrote:

Nice one.

Just one correction to my original post, the link to my gist is
Vagrant delete Chef node and Client on destroy · GitHub and not the one I sent before (that was a
reference).

I like your REST approach, though, and will certainly have a look at that.

Thanks,

Cassiano Leal

On Thursday, December 6, 2012 at 12:04, Jesse Nelson wrote:

meant to say "no subshell" not "syscall"

On Thu, Dec 6, 2012 at 11:04 PM, Jesse Nelson spheromak@gmail.com wrote:

You can check out the code in my chef-sandbox that does this using the
vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

Change:

::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef', 'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal cassianoleal@gmail.comwrote:

I was trying to find a solution for that on the web, and the two
references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a bit
from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are
welcome.

Cheers!

Cassiano Leal

Cassiano_Leal · December 7, 2012, 6:17pm

It would be nice to know the reasoning behind not using the REST client.

When I have the time, I'll experiment with both before deciding the way forward.

Thanks!

Cassiano Leal

On Friday, December 7, 2012 at 15:58, steve . wrote:

I seem to recall someone from Opscode steering people away from making direct calls using Chef's internal REST client for some reason. I'd do it through the Knife object, something like (untested code alert):

Chef::ClientDelete.run(env[:vm].config.vm.host_name)

On Thu, Dec 6, 2012 at 7:48 AM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

Nice one.

Just one correction to my original post, the link to my gist is Vagrant delete Chef node and Client on destroy · GitHub and not the one I sent before (that was a reference).

I like your REST approach, though, and will certainly have a look at that.

Thanks,

Cassiano Leal

On Thursday, December 6, 2012 at 12:04, Jesse Nelson wrote:

meant to say "no subshell" not "syscall"

On Thu, Dec 6, 2012 at 11:04 PM, Jesse Nelson <spheromak@gmail.com (mailto:spheromak@gmail.com)> wrote:

You can check out the code in my chef-sandbox that does this using the vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

Change:
::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef', 'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

I was trying to find a solution for that on the web, and the two references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a bit from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are welcome.

Cheers!

Cassiano Leal

Adam_Jacob · December 7, 2012, 7:29pm

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" cassianoleal@gmail.com wrote:

It would be nice to know the reasoning behind not using the REST client.

When I have the time, I'll experiment with both before deciding the way
forward.

Thanks!

Cassiano Leal

On Friday, December 7, 2012 at 15:58, steve . wrote:

I seem to recall someone from Opscode steering people away from making
direct calls using Chef's internal REST client for some reason. I'd do
it through the Knife object, something like (untested code alert):

Chef::ClientDelete.run(env[:vm].config.vm.host_name)

On Thu, Dec 6, 2012 at 7:48 AM, Cassiano Leal cassianoleal@gmail.com
wrote:

Nice one.

Just one correction to my original post, the link to my gist is
Vagrant delete Chef node and Client on destroy · GitHub https://gist.github.com/4223941 and not
the one I sent before (that was a reference).

I like your REST approach, though, and will certainly have a look at that.

Thanks,

Cassiano Leal

On Thursday, December 6, 2012 at 12:04, Jesse Nelson wrote:

meant to say "no subshell" not "syscall"

On Thu, Dec 6, 2012 at 11:04 PM, Jesse Nelson spheromak@gmail.com wrote:

You can check out the code in my chef-sandbox that does this using the
vagrant provisioner class and chef client code directly (no syscall:

chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub

<chef-sandbox/Vagrantfile at develop · spheromak/chef-sandbox · GitHub
6>

Change:

::Chef::Config.from_file(File.join( File.dirname(FILE), 'chef',
'knife.rb'))

To point to your knife.rb location.
Pop the rest in your vagrant file, and you should be good.

On Thu, Dec 6, 2012 at 9:03 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

I was trying to find a solution for that on the web, and the two
references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm
-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a
bit from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are
welcome.

Cheers!

Cassiano Leal

reset · December 7, 2012, 8:13pm

I wrote a Chef API wrapper with a clean DSL that you can find here: GitHub - berkshelf/ridley: A reliable Chef API client with a clean syntax. You should be able to very easily destroy the client/node with just a few lines of code.

On a side note this is a good point that we don't clean up after ourselves when we destroy a Vagrant VM. I'm not sure if you are using Berkshelf or not, but I'm going to create a ticket so when using the Chef Client provisioner that there is a configurable option to enable "clean up" on destroy.

--
Jamie Winsor
@resetexistence

On Thursday, December 6, 2012 at 4:03 AM, Cassiano Leal wrote:

I was trying to find a solution for that on the web, and the two references that made more sense were:

http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/
delete vagrant vm's chef client and node from chef server on destroy · GitHub

Neither worked out of the box, so I hacked my own solution, adapting a bit from each, and came to this:

delete vagrant vm's chef client and node from chef server on destroy · GitHub

Feel free to use it if you find it useful. Comments and suggestions are welcome.

Cheers!

Cassiano Leal

kallistec · December 7, 2012, 8:24pm

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

Cassiano_Leal · December 7, 2012, 11:48pm

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

reset · December 8, 2012, 12:58am

Here is the ticket: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

Cassiano_Leal · December 8, 2012, 3:16pm

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

reset · December 8, 2012, 6:08pm

It probably is more appropriate to put it into Vagrant's chef_client provisioner

--
Jamie Winsor
@resetexistence

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

Cassiano_Leal · December 8, 2012, 9:05pm

github.com/hashicorp/vagrant

Clean up Chef Server on destruction if Chef Client provisioner

opened 09:04PM - 08 Dec 12 UTC

closed 05:07AM - 29 Aug 13 UTC

c10l

Vagrant should clean up the Chef Server after a virtual machine is destroyed by:… - deleting the created node - deleting the created client for the node This is an exact copy (s/Berkshelf/Vagrant/) of https://github.com/RiotGames/berkshelf/issues/264 . It just makes more sense for Vagrant to do that, since that's who creates the node and client in the first place. This gist can be used as a starting point: https://gist.github.com/4223941 Also this thread on the Chef mailing list has more information about how this could be implemented: http://lists.opscode.com/sympa/arc/chef/2012-12/msg00141.html

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

Cassiano_Leal · December 9, 2012, 6:26pm

I created pull requests on the Vagrant issue (Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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_Ojeda_Croissi · December 10, 2012, 4:35am

I believe Mitchell has closed, time ago, a similar issue:

github.com/hashicorp/vagrant

Vagrant destroy should remove client and node from chef server

opened 10:24AM - 31 Mar 11 UTC

closed 11:26PM - 11 Dec 11 UTC

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.

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 cassianoleal@gmail.com wrote:

I created pull requests on the Vagrant issue
(Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your
opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" cassianoleal@gmail.com 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

Cassiano_Leal · December 10, 2012, 10:20am

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:
Vagrant destroy should remove client and node from chef server · Issue #336 · hashicorp/vagrant · GitHub

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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

I created pull requests on the Vagrant issue
(Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your
opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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

Juanje Ojeda - Las Palmas de Gran Canaria, España, Personal trainer | about.me

Erik_Hollensbe1 · December 10, 2012, 4:21pm

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 cassianoleal@gmail.com 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:
Vagrant destroy should remove client and node from chef server · Issue #336 · hashicorp/vagrant · GitHub

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 cassianoleal@gmail.com wrote:

I created pull requests on the Vagrant issue
(Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your
opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" cassianoleal@gmail.com 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

Juanje Ojeda - Las Palmas de Gran Canaria, España, Personal trainer | about.me

Joshua_Timberman · December 11, 2012, 5:41am

Back in March, I wrote about a multi-vm vagrantfile I use for testing0.
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!

gist.github.com

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

vagrantfile.rb

module Vagrant
  module Provisioners
    class ChefClient < Chef
      def cleanup
        if env[:vm].config.vm.host_name
          puts `sh -c 'knife client delete #{env[:vm].config.vm.host_name} -y'`
          puts `sh -c 'knife node delete #{env[:vm].config.vm.host_name} -y'`
        else
          puts "No host_name was defined for the box... unable to remove it from chef"
        end

This file has been truncated. show original

-joshua

/

On 12/9/12 9:35 PM, "Juanje Ojeda Croissier" juanje.ojeda@gmail.com
wrote:

I believe Mitchell has closed, time ago, a similar issue:
Vagrant destroy should remove client and node from chef server · Issue #336 · hashicorp/vagrant · GitHub

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 cassianoleal@gmail.com
wrote:

I created pull requests on the Vagrant issue
(Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your
opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" cassianoleal@gmail.com 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.

Cassiano_Leal · December 11, 2012, 10:21am

That's exactly the same approach I took (bar a few technicalities). I like the approach, it works great.

My point, though, is that I shouldn't need to go into my Vagrantfiles and paste into each one of them the exact same snippet of code in order to achieve something that's really no more than the reverse of what Vagrant did when it spun up the VM.

I'm using my patched Vagrant, and so far it's been flawless!

--
Cassiano Leal

On Tuesday, December 11, 2012 at 03:41, Joshua Timberman wrote:

Back in March, I wrote about a multi-vm vagrantfile I use for testing0.
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!

Put this at the end of a Vagrantfile that uses the chef-client provisioner · GitHub

-joshua

/

On 12/9/12 9:35 PM, "Juanje Ojeda Croissier" <juanje.ojeda@gmail.com (mailto:juanje.ojeda@gmail.com)>
wrote:

I believe Mitchell has closed, time ago, a similar issue:
Vagrant destroy should remove client and node from chef server · Issue #336 · hashicorp/vagrant · GitHub

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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
wrote:

I created pull requests on the Vagrant issue
(Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub). Chime in with your
opinions and comments!

--
Cassiano Leal

On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:

Clean up Chef Server on destruction if Chef Client provisioner · Issue #1253 · hashicorp/vagrant · GitHub

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
reset (Jamie Stormbreaker) · GitHub

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: Clean up Chef Server on destruction if Chef Client provisioner · Issue #264 · berkshelf/berkshelf · GitHub

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

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" <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> 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.

Topic		Replies	Views
Released gem vagrant-butcher for cleaning up Chef server Chef Infra (archive)	1	288	December 17, 2012
Private Chef: registering a client for an existing node Chef Infra (archive)	6	516	January 17, 2013
Deleting nodes/clients using chef-client or chef-shell Chef Infra (archive)	1	340	May 20, 2014
Managing node client deletions as you recreate them Chef Infra (archive)	0	237	January 6, 2012
Node client deletions before recreating the same client Chef Infra (archive)	3	313	January 19, 2012

Cheers!

Cheers!

Cheers!

Thanks,

Cheers!

Thanks,

Cheers!

Thanks!

Thanks,

Cheers!

Thanks!

Thanks,

Cheers!

Cheers!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Cheers guys!

Related topics