chef-runner fails with berks 3.1.3 vendoring cookbooks

[erichelgeson]

Using ChefDK and chef-runner I get the following:

$ chef-runner -M 938a943
INFO: Starting chef-runner (v0.5.0 darwin/amd64)
INFO: Preparing local files
INFO: Installing cookbook dependencies with Berkshelf resolver
DEPRECATED: `berks install --path [PATH}` has been replaced by `berks vendor`.
DEPRECATED: Re-run your command as `berks vendor [PATH]` or see `berks help vendor`.
ERROR: exit status 1

$ berks -v
3.1.3
$ chef-runner --version
chef-runner v0.5.0 darwin/amd64

Using this cookbook and a machine provisioned by test kitchen.

Using the binary distribution of chef-runner.

Let me know if there is any other debugging info that would help.

Also, it would be nice to ignore Gemfiles (since i'm using chefdk, i don't need to bundle install)

[erichelgeson]

Gah! just saw #12 so nevermind!

[mlafeldt]

Hey!

1) Yes, support for Berkshelf v3 is going to be part of chef-runner 0.6. So please use go get -u until the release is out.

2) As you're using chef-runner with Test Kitchen, I want to ask you something: do you think it would be a useful feature if you could pass the Test Kitchen instance names directly to chef-runner (instead of the UUID)?

For example:

$ chef-runner -M default-ubuntu-1204

3)

Also, it would be nice to ignore Gemfiles (since i'm using chefdk, i don't need to bundle install)

At the moment chef-runner simply prepends bundle exec in case a Gemfile exists. I was convinced this would always be a good idea, but never thought about a special environment like ChefDK. Any idea how we can defer the right thing to do here (without breaking the old behavior)? A configuration option might be the only, well, option here.

Looking forward to your feedback. :)

[mlafeldt]

@erichelgeson I think I found a good solution to 3). Whenever you use chef exec or chef shell-init, $PATH is modified so that ChefDK gets used. In chef-runner, I can check if $PATH includes "chefdk" and disable bundle exec accordingly. Cool?

[mlafeldt]

While I've got some working code for the proposed solution, it looks like people actually use Ruby and Bundler inside ChefDK, e.g. http://jtimberman.housepub.org/blog/2014/04/30/chefdk-and-ruby/

So disabling it globally in ChefDK seems to be a bad idea.

[erichelgeson]

What about doing --no-berks or --no-bundle to disable those specific features (may be more in the future)? Then having a global ~/.chef-runner where I can specify global options (like .gemrc/etc).

Ya if you could map the guild from the test-kitchen name, that'd be cool! Though I many times run more than one VM at a time and converge more than 1 at a time, so ether have to address or only allow one and error if it matches multiple.

[mlafeldt]

What about doing --no-berks or --no-bundle to disable those specific features (may be more in the future)? Then having a global ~/.chef-runner where I can specify global options (like .gemrc/etc).

I'm still unsure what's the best way here. The Chef folks aren't really clear about it either. Sorry.

Ya if you could map the guild from the test-kitchen name, that'd be cool! Though I many times run more than one VM at a time and converge more than 1 at a time, so ether have to address or only allow one and error if it matches multiple.

Speaking of many VMs, I was actually thinking about the ability to provision multiple machines at once. For example, chef-runner -M foo,bar would provision two machines using the same recipes. I'm not sure if provisioning many machines with the same recipes is a general use case more people would be interested in though.

[mlafeldt]

Ya if you could map the guild from the test-kitchen name, that'd be cool!

I guess you're going to like #20. :)