The vagrant berkshelf plugin

#1

Hello,

I managed to take from the small README that this plugin has on github that it helps
vagrant 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.

#2

Pardon the chaff….I am pretty sure that feeding the —debug flag to vagrant, thru
my 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 chahn@cognitivemedicine.com wrote:

Hello,

I managed to take from the small README that this plugin has on github that it helps
vagrant 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.

#3

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, thru
my 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
<chahn@cognitivemedicine.com mailto:chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on
github that it helps
vagrant 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.

#4

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.

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.

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 lamont@chef.io 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, thru
my 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 chahn@cognitivemedicine.com
wrote:

Hello,

I managed to take from the small README that this plugin has on github
that it helps
vagrant 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.

#5

Bear in mind that “kitchen test” does try to terminate the instances, but
"kitchen verify" does not.

–
~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Mon, May 4, 2015 at 4:16 PM, Greg Barker fletch@fletchowns.net wrote:

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.

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.

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 lamont@chef.io 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, thru
my 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 <
chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on github
that it helps
vagrant 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.

#6

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:

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.

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.

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 <lamont@chef.io
mailto:lamont@chef.io> 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, thru
my 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
<chahn@cognitivemedicine.com
<mailto:chahn@cognitivemedicine.com>> wrote:

Hello,

I managed to take from the small README that this plugin has on
github that it helps
vagrant 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.
#7

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 forgetting

Here’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” ]; then
cd .kitchen/kitchen-vagrant/*2/ && vagrant reload && cd - else chef exec kitchen @
fi
}

-Eric Helgeson
@nulleric https://twitter.com/nulleric
https://usingchef.com

On Tue, May 5, 2015 at 10:50 AM, Lamont Granquist lamont@chef.io 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:

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.

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.

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 lamont@chef.io 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, thru
my 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 <
chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on github
that it helps
vagrant 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.

#8

Hello Greg,

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.

I think this test-kitchen driver could fit your needs for VMs that should
stick around for a while.

Kindest Regards.
Konstantin.

On Wed, May 6, 2015 at 12:47 AM, Eric Helgeson erichelgeson@gmail.com
wrote:

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 forgetting

Here’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” ]; then
cd .kitchen/kitchen-vagrant/*2/ && vagrant reload && cd - else chef exec kitchen @
fi
}

-Eric Helgeson
@nulleric https://twitter.com/nulleric
https://usingchef.com

On Tue, May 5, 2015 at 10:50 AM, Lamont Granquist lamont@chef.io 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:

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.

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.

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 lamont@chef.io 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, thru
my 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 <
chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on github
that it helps
vagrant 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.

#9

I’m not quite sure I follow you Konstantin. Do you mean this is good for if
you have a kitchen box that you need to send large volumes of data to?

On Thu, Jun 18, 2015 at 11:14 PM, Konstantin Lysenko <
konstantin@atalanta-systems.com> wrote:

Hello Greg,

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.

I think this test-kitchen driver could fit your needs for VMs that should
stick around for a while.
https://github.com/neillturner/kitchen-ssh

Kindest Regards.
Konstantin.

On Wed, May 6, 2015 at 12:47 AM, Eric Helgeson erichelgeson@gmail.com
wrote:

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 forgetting

Here’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” ]; then
cd .kitchen/kitchen-vagrant/*2/ && vagrant reload && cd - else chef exec kitchen @
fi
}

-Eric Helgeson
@nulleric https://twitter.com/nulleric
https://usingchef.com

On Tue, May 5, 2015 at 10:50 AM, Lamont Granquist lamont@chef.io 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:

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.

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.

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 lamont@chef.io
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, thru
my 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 <
chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on
github that it helps
vagrant 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.

–
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

#10

Hi Yoshi,

Greg wondered - is it possible to use test-kitchen if you have persistent
instance (not ephemeral).

So I told that kitchen-ssh driver fit well for that purpose.

Because kitchen-ssh driver doesn’t create/destroy hosts, it only
converges/runs tests on hosts.

Kindest Regards.
Konstantin.

On Sat, Jun 20, 2015 at 1:08 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

I’m not quite sure I follow you Konstantin. Do you mean this is good for
if you have a kitchen box that you need to send large volumes of data to?

On Thu, Jun 18, 2015 at 11:14 PM, Konstantin Lysenko <
konstantin@atalanta-systems.com> wrote:

Hello Greg,

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.

I think this test-kitchen driver could fit your needs for VMs that should
stick around for a while.
https://github.com/neillturner/kitchen-ssh

Kindest Regards.
Konstantin.

On Wed, May 6, 2015 at 12:47 AM, Eric Helgeson erichelgeson@gmail.com
wrote:

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 forgetting

Here’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” ]; then
cd .kitchen/kitchen-vagrant/*2/ && vagrant reload && cd - else chef exec kitchen @
fi
}

-Eric Helgeson
@nulleric https://twitter.com/nulleric
https://usingchef.com

On Tue, May 5, 2015 at 10:50 AM, Lamont Granquist lamont@chef.io
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:

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.

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.

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 lamont@chef.io
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, thru
my 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 <
chahn@cognitivemedicine.com> wrote:

Hello,

I managed to take from the small README that this plugin has on github
that it helps
vagrant 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.

–
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com