Chef-DK Question

[Torben_Knerr]

Ohai chefs!

Glad to see that Chef-DK brings together the most commly used tools in the
chef community. Not only because they are now “officially recommended” but
also for the reduced likelihood of dependency conflicts (think of the json
gem). Sweet!

One thing I didn’t fully understand though: How is it intended to work with
different projects / cookbook repos that have different versions of
chefspec, foodcritic, test-kitchen, etc?

I probably can’t / don’t want to upgrade all my repos everytime a new
version of Chef-DK comes out. Is this coupling intended? The fact that it
bundles chefspec, foodcritic and test-kitchen makes it look like so…

From my experience with bills kitchen [0] (“all you need for cooking with
Chef on windows” - think of it as a more opinionated, windows-only
Chef-DK++) I went down the same path:

First I bundled not only Chef and Vagrant but also pre-installed loads of
related gems in a configuration that would not conflict with each other.

This got more and more painful every time a new version of one of the gems
(e.g. chefspec) came out. Upgrading the gem was a global operation and thus
affected all projects I was working with.

Since this was way too annoying I switched to another approach [1]:

1. bills kitchen now only bundles Ruby (+DevKit), Chef and Vagrant
2. bundler is the only pre-installed gem
3. bindler [2] is the only pre-insalled vagrant plugin

All other gems (like berkshelf, chefspec, foodcritic, test-kitchen, etc)
and vagrant plugins (like vagrant-omnibus, vagrant-berkshelf, etc) are now
managed per project in a Gemfile or plugins.json respectively.

Having the core tools decoupled from the other gems gave me a great deal of
flexibility. I can now work on older projects as well as newer projects
using the same version of bills kitchen, and I’m no longer forced to
upgrade older projects just because of a newer version of bills kitchen.

Right now it seems to me that Chef-DK follows the approach to bundle
everything. Sure, you can still use Gemfiles in your projects, but wouldn’t
this end up in confusion due to the different Ruby installation (System
ruby vs. Chef-DK embedded ruby)?

What’s the intended usage of Chef-DK here?

Cheers,
Torben

[0] https://github.com/tknerr/bills-kitchen
[1] compare https://github.com/tknerr/bills-kitchen/blob/0.10/README.md
with master
[2] https://github.com/fgrehm/bindler

[Lamont_Granquist_OLD]

chef-dk really does two things:

1. bundles everything together (ruby, chef, berkshelf, TK, nokogiri,
   etc)
2. also has the 'chef' workflow tool installed by the chefdk gem

we're also going to suggest for new users to let chefdk take over your
system a little bit and you'll use that instead of your system ruby
(and /opt/chefdk/embedded/bin will need to be in your path). in that
case you can bundle install tools into chefdk and use it in preference
to your system ruby (ideally not having any system ruby installed at
all). that'll create some drift in the gems installed in chefdk, but
at that point you should be check in Gemfile.lock files and bundle
install/bundle exec'ing anyway.

but, if you've already solved this problem and don't need/want the
packaging problem solved for you, then you can skip using the chefdk
omnibus package that we ship entirely and instead use rvm/rbenv/chruby
to manage your ruby installation and gem install / bundle install your
tools like you have been doing. then what you'll get out of the chefdk
gem, is the chef command line tool, which is going to replace all the
use cases from knife-spork, berks uploading, berks cookbook generators,
berkflow, meez, etc, on top of integration with planned Chef 12/13
features to make cookbook workflow easier.

however, there will also be some packaging things that you'll missing
with chefdk like the 'appbundler' way that we package command line
tools, which reduces start up cost considerably and makes knife and
other command line ruby tools a lot more snappy. we're also not going
to be supporting debugging system rubies. you're going to need to be
able to get the same ruby version installed that we ship in the omnibus
packages. if you go the DIY route you'll be accepting self-support,
and at a some point you may find it a lot easier just to install the
chefdk packages (you may run into bugs closed 'wontfix - cannot
replicate in chefdk omnibus packages').

On Sat May 31 02:39:25 2014, Torben Knerr wrote:

Ohai chefs!

Glad to see that Chef-DK brings together the most commly used tools in
the chef community. Not only because they are now "officially
recommended" but also for the reduced likelihood of dependency
conflicts (think of the json gem). Sweet!

One thing I didn't fully understand though: How is it intended to work
with different projects / cookbook repos that have different versions
of chefspec, foodcritic, test-kitchen, etc?

I probably can't / don't want to upgrade all my repos everytime a new
version of Chef-DK comes out. Is this coupling intended? The fact that
it bundles chefspec, foodcritic and test-kitchen makes it look like so...

From my experience with bills kitchen [0] ("all you need for cooking
with Chef on windows" - think of it as a more opinionated,
windows-only Chef-DK++) I went down the same path:

First I bundled not only Chef and Vagrant but also pre-installed loads
of related gems in a configuration that would not conflict with each
other.

This got more and more painful every time a new version of one of the
gems (e.g. chefspec) came out. Upgrading the gem was a global
operation and thus affected all projects I was working with.

Since this was way too annoying I switched to another approach [1]:

1. bills kitchen now only bundles Ruby (+DevKit), Chef and Vagrant
2. bundler is the only pre-installed gem
3. bindler [2] is the only pre-insalled vagrant plugin

All other gems (like berkshelf, chefspec, foodcritic, test-kitchen,
etc) and vagrant plugins (like vagrant-omnibus, vagrant-berkshelf,
etc) are now managed per project in a Gemfile or plugins.json
respectively.

Having the core tools decoupled from the other gems gave me a great
deal of flexibility. I can now work on older projects as well as newer
projects using the same version of bills kitchen, and I'm no longer
forced to upgrade older projects just because of a newer version of
bills kitchen.

Right now it seems to me that Chef-DK follows the approach to bundle
everything. Sure, you can still use Gemfiles in your projects, but
wouldn't this end up in confusion due to the different Ruby
installation (System ruby vs. Chef-DK embedded ruby)?

What's the intended usage of Chef-DK here?

Cheers,
Torben

[0] GitHub - tknerr/bills-kitchen: All you need for cooking with Chef and Vagrant on Windows you will find in Bill's Kitchen
[1] compare
https://github.com/tknerr/bills-kitchen/blob/0.10/README.md with master
[2] GitHub - fgrehm/bindler: [DEPRECATED] Dead easy Vagrant plugins management

[Torben_Knerr]

Hi Lamont,

thanks a lot!

Your answer, along with Joshuas Blog Post I just found, answers everything:
http://jtimberman.housepub.org/blog/2014/04/30/chefdk-and-ruby/

Looking forward for the first windows build to come out!

Cheers,
Torben

P.S.: appbundler looks interesting too!

On Sat, May 31, 2014 at 9:11 PM, Lamont Granquist lamont@opscode.com
wrote:

chef-dk really does two things:

1. bundles everything together (ruby, chef, berkshelf, TK, nokogiri, etc)
2. also has the 'chef' workflow tool installed by the chefdk gem

we're also going to suggest for new users to let chefdk take over your
system a little bit and you'll use that instead of your system ruby (and
/opt/chefdk/embedded/bin will need to be in your path). in that case you
can bundle install tools into chefdk and use it in preference to your
system ruby (ideally not having any system ruby installed at all). that'll
create some drift in the gems installed in chefdk, but at that point you
should be check in Gemfile.lock files and bundle install/bundle exec'ing
anyway.

but, if you've already solved this problem and don't need/want the
packaging problem solved for you, then you can skip using the chefdk
omnibus package that we ship entirely and instead use rvm/rbenv/chruby to
manage your ruby installation and gem install / bundle install your tools
like you have been doing. then what you'll get out of the chefdk gem, is
the chef command line tool, which is going to replace all the use cases
from knife-spork, berks uploading, berks cookbook generators, berkflow,
meez, etc, on top of integration with planned Chef 12/13 features to make
cookbook workflow easier.

however, there will also be some packaging things that you'll missing with
chefdk like the 'appbundler' way that we package command line tools, which
reduces start up cost considerably and makes knife and other command line
ruby tools a lot more snappy. we're also not going to be supporting
debugging system rubies. you're going to need to be able to get the same
ruby version installed that we ship in the omnibus packages. if you go the
DIY route you'll be accepting self-support, and at a some point you may
find it a lot easier just to install the chefdk packages (you may run into
bugs closed 'wontfix - cannot replicate in chefdk omnibus packages').

On Sat May 31 02:39:25 2014, Torben Knerr wrote:

Ohai chefs!

Glad to see that Chef-DK brings together the most commly used tools in
the chef community. Not only because they are now "officially
recommended" but also for the reduced likelihood of dependency
conflicts (think of the json gem). Sweet!

One thing I didn't fully understand though: How is it intended to work
with different projects / cookbook repos that have different versions
of chefspec, foodcritic, test-kitchen, etc?

I probably can't / don't want to upgrade all my repos everytime a new
version of Chef-DK comes out. Is this coupling intended? The fact that
it bundles chefspec, foodcritic and test-kitchen makes it look like so...

From my experience with bills kitchen [0] ("all you need for cooking
with Chef on windows" - think of it as a more opinionated,
windows-only Chef-DK++) I went down the same path:

First I bundled not only Chef and Vagrant but also pre-installed loads
of related gems in a configuration that would not conflict with each
other.

This got more and more painful every time a new version of one of the
gems (e.g. chefspec) came out. Upgrading the gem was a global
operation and thus affected all projects I was working with.

Since this was way too annoying I switched to another approach [1]:

1. bills kitchen now only bundles Ruby (+DevKit), Chef and Vagrant
2. bundler is the only pre-installed gem
3. bindler [2] is the only pre-insalled vagrant plugin

All other gems (like berkshelf, chefspec, foodcritic, test-kitchen,
etc) and vagrant plugins (like vagrant-omnibus, vagrant-berkshelf,
etc) are now managed per project in a Gemfile or plugins.json
respectively.

Having the core tools decoupled from the other gems gave me a great
deal of flexibility. I can now work on older projects as well as newer
projects using the same version of bills kitchen, and I'm no longer
forced to upgrade older projects just because of a newer version of
bills kitchen.

Right now it seems to me that Chef-DK follows the approach to bundle
everything. Sure, you can still use Gemfiles in your projects, but
wouldn't this end up in confusion due to the different Ruby
installation (System ruby vs. Chef-DK embedded ruby)?

What's the intended usage of Chef-DK here?

Cheers,
Torben

[0] GitHub - tknerr/bills-kitchen: All you need for cooking with Chef and Vagrant on Windows you will find in Bill's Kitchen
[1] compare
https://github.com/tknerr/bills-kitchen/blob/0.10/README.md with master
[2] GitHub - fgrehm/bindler: [DEPRECATED] Dead easy Vagrant plugins management