General discussion about Chef

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


Chronological Thread 
  • From: Cassiano Leal < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Delete node and client when destroying Vagrant VM
  • Date: Tue, 11 Dec 2012 08:21:10 -0200
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 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!




-joshua

[0]:
/




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

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

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
opinions and comments!

--
Cassiano Leal

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


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

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:


--
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" < "> > 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:

In conclusion, there are trade-offs either way, but both ways are valid.


Archive powered by MHonArc 2.6.16.

§