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 LealOn 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 fileto automatically cleanup. As a disqus comment, it didn't format well, butI posted it here. Thanks, Eric Edgar for this!-joshua[0]:/On 12/9/12 9:35 PM, "Juanje Ojeda Croissier" < " target="_blank"> >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 fewuser-experience issues.The easiest way to do this would be to use the Chef installationalready in the VM to remove the node and such. However, during adestroy, 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, butrequires knife to be installed. knife must also already be setup as aclient of the Chef server, which it isn't by default. This maysurprise people. An option is to make this feature an option which isdisabled by default and only enable it via a provisioner option.Vagrant can't use the Chef API directly because the computer might notbe setup as a client and doing all that just to remove another node isoften defeating the purpose and is also very complicated.I do believe this is an important feature, but the complexity israther high. Continuing with the plugin approach for users who needthis may be the best approach. I'd like feedback."On Sun, Dec 9, 2012 at 6:26 PM, Cassiano Leal < " target="_blank"> >wrote:I created pull requests on the Vagrant issue(https://github.com/mitchellh/vagrant/issues/1253). Chime in with youropinions and comments!--Cassiano LealOn Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:I wonder if we can close the one in Berkshelf.--Cassiano LealOn Saturday, December 8, 2012 at 16:08, Jamie Winsor wrote:It probably is more appropriate to put it into Vagrant's chef_clientprovisioner--Jamie Winsor@resetexistenceOn Saturday, December 8, 2012 at 7:16 AM, Cassiano Leal wrote:I see that you opened that ticket on Berkshelf, but wouldn't it makemoresense if Vagrant's chef_client provisioner would do that job instead?Afterall, it's Vagrant who creates the client and node in the Chef server.--Cassiano LealOn Friday, December 7, 2012 at 22:58, Jamie Winsor wrote:Here is the ticket: https://github.com/RiotGames/berkshelf/issues/264--Jamie Winsor@resetexistenceOn Friday, December 7, 2012 at 3:48 PM, Cassiano Leal wrote:Wow, thanks for the enlightening answer Daniel, that's exactly the sortofthing I wanted to understand. I'll study both approaches before I decidewhich one to go with.
Jamie: Ridley looks great, thanks for writing that. Also yeah, I'm usingBerkshelf, and having that sort of functionality built into Vagrantwould befantastic. Let me know the ticket number when you create it so that Icanchime in, if you don't mind!Adam: that comment made my afternoon! :)Cheers guys!--Cassiano LealOn 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.AdamOn 12/7/12 10:17 AM, "Cassiano Leal" < " target="_blank"> > 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 changesfromyou. For example, we'd like to some day remove the json_class stufffrom theAPI, which means that the data you get back from Chef::REST willprobably bea Hash instead of a Chef::Node (or whatever you asked for). If(continuingthe example) you use the methods on Chef::Node, you wouldn't beimpacted bythis. Contrarily, the higher up the chain you go, there's more thingsthatcould be changed. As a concrete example, the #save method is defined onallof the model classes to try to update and then fall back to create (orviceversa, it's not 100% consistent). We'd like to change this at somepoint sothere are separate create and update methods since 99% of the time youknowwhich one you need.Either way, changes to the API or to core model class functionality aregenerally 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 timeonthis 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.