I like test-kitchen but it doesn't seem to fit well with the use case of a VM that should stick around for awhile.
Getting but off topic here, but there has been a lot of discussion on this point on github issues as well - https://github.com/test-kitchen/test-kitchen/issues/350 summing up that while agree it should exist, no one has time to do it.There are many differences between vagrant/kitchen and I find myself having to choose or hack many times while setting up a project, or having both for various reasons -* MultiVM support* Vagrant mounts cookbook/nodes/etc dirs, kitchen copies them over* No reload/suspend/etc commands in kitchen* Local Mode runs as `chef-solo -z` in vagrant, `chef-client -z` in kitchen* More I'm forgettingHere's a hack to get reload on your mac/linux machine with chefdk. Add it to your bash profile. Works for me, can't say it'd work in others use case (it assumes many things) -kitchen() {if [ "$1" == "reload" ]; thencd .kitchen/kitchen-vagrant/*$2/ && vagrant reload && cd -elsechef exec kitchen $@fi}-Eric HelgesonOn Tue, May 5, 2015 at 10:50 AM, Lamont Granquist < " target="_blank"> > wrote:
Well you can use 'kitchen converge' to have the VM stick around after running chef client.
If there's use cases that are missing from kitchen that you need then it would be pretty easy to submit PRs to add those so that you could e.g. 'kitchen provision' instead of cd'ing into the directory with the Vagrantfile and doing a 'vagrant provision'. Any jankiness there should be easily fixable.
On 05/04/2015 04:16 PM, Greg Barker wrote:
I do all my development work in VMs, so we have a cookbook that will spin up a full dev environment (install a desktop manager, install intellij, etc). With this VM I use `vagrant up` and `vagrant provision` and `vagrant halt` all the time and it seems to fit well with this use case.Lamont -I like test-kitchen but it doesn't seem to fit well with the use case of a VM that should stick around for awhile.
It seems like test-kitchen wasn't meant to be used for VMs that stick around, everything is geared towards the VM being destroyed at the end of a run. Sure you can run the vagrant commands on the generated vagrantfile but it feels kinda janky.
Maybe my perception needs some adjustment but I thought I should share it anyways.
Greg
On Mon, May 4, 2015 at 10:06 AM, Lamont Granquist < " target="_blank"> > wrote:
Generally test-kitchen is a better approach than using vagrant-berkshelf and vagrant-omnibus. The latter two are somewhat deprecated and are mostly falling behind test-kitchen's features.
On 05/02/2015 06:23 PM, Christopher Hahn wrote:
Pardon the chaff….I am pretty sure that feeding the —debug flag to vagrant, thrumy build.gradle exec block, will tell me what I need to know.
Take care,
Christopher
On May 2, 2015, at 6:00 PM, Christopher Hahn < " target="_blank"> > wrote:
Hello,
I managed to take from the small README that this plugin has on github that it helpsvagrant sync a berkshelf on the Node so that it can then launch chef-solo to provision it.
I would love to find a bit more documentation was to just *what it is doing during vagrant actions*
i.e. what precisely happens between: and the:
17:54:27.468 [INFO] [org.gradle.process.internal.DefaultExecHandle] Starting process 'command '/usr/bin/vagrant''. Working directory: /Users/chahn/Projects/vistacore/cdsdashboard/infrastructure/vagrant/virtualbox/cdsdashboard Command: /usr/bin/vagrant provision cdsdashboard
and the:
Running chef-solo…
I am certain that I am needing to be directed elsewhere…this is just where I know to start.
Thank you,
Christopher
P.S. I did add a comment/question on the hub as well.
Archive powered by MHonArc 2.6.16.