ChefDK and collaborating with others


#1

I’m somewhat new to Chef and Ruby in general, so please bear with me ( and feel free to correct any misguided statements! )

From what I understand, pre-ChefDK, people would use bundler to pin the gem versions they used to develop/test their application/cookbook. I slap it all into a Gemfile, bundle install, commit the Gemfile.lock. You download my repo, you bundle install and you immediately have all the same gem versions that I used.

My confusion stems with how this is supposed to work with ChefDK. Suppose that I use ChefDK to create my cookbook, do all my development and testing and release it to a public repo.? My colleague, however, doesn’t have ChefDK and grabs my repo. How is he supposed to know what gems I used? My first answer would be - I either document it in the README or I just say ‘Install ChefDK v0.3.5’. Another option would be to manually create a Gemfile for everything that I used out of ChefDK and include that along with my repo? But in both cases, I’m having to keep some extra piece of information up to date with everything I’m using out of ChefDK ( or just telling him he better install it ). Am I missing something there?

The second scenario I’m hazy about is when you get into the situation when we start drifting between ChefDK versions. Perhaps I haven’t upgraded my ChefDK for awhile and you’re on the latest and greatest. What’s keeping us in sync, so that we’re using the same versions of Test Kitchen, ChefSpec, etc? Or does it not matter, because in general, the differences between the gems provided in different ChefDK versions isn’t a big enough concern?

I understand ( I think ), that if I start using 3rd party gems that aren’t included in ChefDK, I should be bundle installing them and including the Gemfile. I think it’s the two scenarios above that I’m unsure about and I’m curious how others are doing this.

I’ve read a few blog posts and the previous mail on the list http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I think I’m still confused enough what the vision/workflow is that I had to ask.

Thanks,

sh


#2

For what its worth, I share your confusion here. We’ve historically used
the Gemfile approach as well and as we transition to ChefDK, I still feels
like we need this… As very simplistic example we use rubocop to enforce
rules (build fails if there are offenses). Since new version introduce new
rules folks with varying levels of the gem and/chefDK get different
results. It’s unclear to me how ChefDK (which as I understand, suggests you
can do away with Gemfiles) solves this issue?

On Thu, Dec 18, 2014 at 3:58 PM, Hajducko, Steven <
Steven_Hajducko@intuit.com> wrote:

I’m somewhat new to Chef and Ruby in general, so please bear with me (
and feel free to correct any misguided statements! )

From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the same
gem versions that I used.

My confusion stems with how this is supposed to work with ChefDK.
Suppose that I use ChefDK to create my cookbook, do all my development and
testing and release it to a public repo.​ My colleague, however, doesn’t
have ChefDK and grabs my repo. How is he supposed to know what gems I
used? My first answer would be - I either document it in the README or I
just say ‘Install ChefDK v0.3.5’. Another option would be to manually
create a Gemfile for everything that I used out of ChefDK and include that
along with my repo? But in both cases, I’m having to keep some extra piece
of information up to date with everything I’m using out of ChefDK ( or just
telling him he better install it ). Am I missing something there?

The second scenario I’m hazy about is when you get into the situation
when we start drifting between ChefDK versions. Perhaps I haven’t upgraded
my ChefDK for awhile and you’re on the latest and greatest. What’s keeping
us in sync, so that we’re using the same versions of Test Kitchen,
ChefSpec, etc? Or does it not matter, because in general, the differences
between the gems provided in different ChefDK versions isn’t a big enough
concern?

I understand ( I think ), that if I start using 3rd party gems that
aren’t included in ChefDK, I should be bundle installing them and including
the Gemfile. I think it’s the two scenarios above that I’m unsure about
and I’m curious how others are doing this.

I’ve read a few blog posts and the previous mail on the list
http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I
think I’m still confused enough what the vision/workflow is that I had to
ask.

Thanks,

sh


#3

yo,

On Fri, Dec 19, 2014 at 10:13 AM, David Petzel davidpetzel@gmail.com wrote:

For what its worth, I share your confusion here. We’ve historically used the
Gemfile approach as well and as we transition to ChefDK, I still feels like
we need this… As very simplistic example we use rubocop to enforce rules
(build fails if there are offenses). Since new version introduce new rules
folks with varying levels of the gem and/chefDK get different results. It’s
unclear to me how ChefDK (which as I understand, suggests you can do away
with Gemfiles) solves this issue?

On Thu, Dec 18, 2014 at 3:58 PM, Hajducko, Steven
Steven_Hajducko@intuit.com wrote:

I’m somewhat new to Chef and Ruby in general, so please bear with me ( and
feel free to correct any misguided statements! )

From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the same
gem versions that I used.

My confusion stems with how this is supposed to work with ChefDK. Suppose
that I use ChefDK to create my cookbook, do all my development and testing
and release it to a public repo. My colleague, however, doesn’t have ChefDK
and grabs my repo. How is he supposed to know what gems I used? My first
answer would be - I either document it in the README or I just say ‘Install
ChefDK v0.3.5’. Another option would be to manually create a Gemfile for
everything that I used out of ChefDK and include that along with my repo?
But in both cases, I’m having to keep some extra piece of information up to
date with everything I’m using out of ChefDK ( or just telling him he better
install it ). Am I missing something there?

The second scenario I’m hazy about is when you get into the situation when
we start drifting between ChefDK versions. Perhaps I haven’t upgraded my
ChefDK for awhile and you’re on the latest and greatest. What’s keeping us
in sync, so that we’re using the same versions of Test Kitchen, ChefSpec,
etc? Or does it not matter, because in general, the differences between the
gems provided in different ChefDK versions isn’t a big enough concern?

I understand ( I think ), that if I start using 3rd party gems that aren’t
included in ChefDK, I should be bundle installing them and including the
Gemfile. I think it’s the two scenarios above that I’m unsure about and I’m
curious how others are doing this.

I’ve read a few blog posts and the previous mail on the list
http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I think
I’m still confused enough what the vision/workflow is that I had to ask.

yo,

ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks’ Gemfiles, or even mega repository
Gemfiles. I don’t think I’ve heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.

One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.

I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn’t take an hour to
compile on smaller rigs :slight_smile:

I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.

hope this helps~

cheers,

–aj

Thanks,

sh


#4

double yo


#5

Thanks AJ, this is exactly what we’ve done as well. Just let ChefDK get all
the rights bits, but we are still using gemfiles and Bundler, I can’t
recall where I saw/heard it, but there was some suggestions that ChefDK
could do away with these complexities.

On Thu, Dec 18, 2014 at 4:23 PM, AJ Christensen <aj@junglistheavy.industries

wrote:

yo,

On Fri, Dec 19, 2014 at 10:13 AM, David Petzel davidpetzel@gmail.com
wrote:

For what its worth, I share your confusion here. We’ve historically used
the
Gemfile approach as well and as we transition to ChefDK, I still feels
like
we need this… As very simplistic example we use rubocop to enforce
rules
(build fails if there are offenses). Since new version introduce new
rules
folks with varying levels of the gem and/chefDK get different results.
It’s
unclear to me how ChefDK (which as I understand, suggests you can do away
with Gemfiles) solves this issue?

On Thu, Dec 18, 2014 at 3:58 PM, Hajducko, Steven
Steven_Hajducko@intuit.com wrote:

I’m somewhat new to Chef and Ruby in general, so please bear with me (
and

feel free to correct any misguided statements! )

From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I
slap

it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the
same

gem versions that I used.

My confusion stems with how this is supposed to work with ChefDK.
Suppose

that I use ChefDK to create my cookbook, do all my development and
testing

and release it to a public repo. My colleague, however, doesn’t have
ChefDK

and grabs my repo. How is he supposed to know what gems I used? My
first

answer would be - I either document it in the README or I just say
’Install

ChefDK v0.3.5’. Another option would be to manually create a Gemfile
for

everything that I used out of ChefDK and include that along with my
repo?

But in both cases, I’m having to keep some extra piece of information
up to

date with everything I’m using out of ChefDK ( or just telling him he
better

install it ). Am I missing something there?

The second scenario I’m hazy about is when you get into the situation
when

we start drifting between ChefDK versions. Perhaps I haven’t upgraded
my

ChefDK for awhile and you’re on the latest and greatest. What’s
keeping us

in sync, so that we’re using the same versions of Test Kitchen,
ChefSpec,

etc? Or does it not matter, because in general, the differences
between the

gems provided in different ChefDK versions isn’t a big enough concern?

I understand ( I think ), that if I start using 3rd party gems that
aren’t

included in ChefDK, I should be bundle installing them and including the
Gemfile. I think it’s the two scenarios above that I’m unsure about
and I’m

curious how others are doing this.

I’ve read a few blog posts and the previous mail on the list
http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I
think

I’m still confused enough what the vision/workflow is that I had to ask.

yo,

ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks’ Gemfiles, or even mega repository
Gemfiles. I don’t think I’ve heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.

One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.

I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn’t take an hour to
compile on smaller rigs :slight_smile:

I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.

hope this helps~

cheers,

–aj

Thanks,

sh


#6

On Thu Dec 18 13:27:41 2014, David Petzel wrote:

Thanks AJ, this is exactly what we’ve done as well. Just let ChefDK
get all the rights bits, but we are still using gemfiles and Bundler,
I can’t recall where I saw/heard it, but there was some suggestions
that ChefDK could do away with these complexities.

I’ve just been adding chef-dk to Gemfiles. This was a little
problematic with the chef-12 it required getting into fights with other
things that required chef-11 deps (test-kitchen in particular), but
that should all be getting ironed out as those other gems are getting
bumps to deal with chef-12.


#7

I avoid Gemfiles in projects where ChefDK already includes the things that
would be installed in the bundler. Think test-kitchen, chefspec, etc.

However, as I do use ChefDK’s Ruby as my primary Ruby VM on my workstation,
I vendor bundles with binstubs in non-Chef project repositories (like my
blog, which is octopress).

E.g.,

bundle install --path=vendor --binstubs

This avoids some weird gem conflicts when they’re installed in my GEM_HOME
(~/.chefdk/gem).

Cheers,
Joshua

On Thu, Dec 18, 2014 at 2:27 PM, David Petzel davidpetzel@gmail.com wrote:

Thanks AJ, this is exactly what we’ve done as well. Just let ChefDK get
all the rights bits, but we are still using gemfiles and Bundler, I can’t
recall where I saw/heard it, but there was some suggestions that ChefDK
could do away with these complexities.

On Thu, Dec 18, 2014 at 4:23 PM, AJ Christensen <
aj@junglistheavy.industries> wrote:

yo,

On Fri, Dec 19, 2014 at 10:13 AM, David Petzel davidpetzel@gmail.com
wrote:

For what its worth, I share your confusion here. We’ve historically
used the
Gemfile approach as well and as we transition to ChefDK, I still feels
like
we need this… As very simplistic example we use rubocop to enforce
rules
(build fails if there are offenses). Since new version introduce new
rules
folks with varying levels of the gem and/chefDK get different results.
It’s
unclear to me how ChefDK (which as I understand, suggests you can do
away
with Gemfiles) solves this issue?

On Thu, Dec 18, 2014 at 3:58 PM, Hajducko, Steven
Steven_Hajducko@intuit.com wrote:

I’m somewhat new to Chef and Ruby in general, so please bear with me (
and

feel free to correct any misguided statements! )

From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I
slap

it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the
same

gem versions that I used.

My confusion stems with how this is supposed to work with ChefDK.
Suppose

that I use ChefDK to create my cookbook, do all my development and
testing

and release it to a public repo. My colleague, however, doesn’t have
ChefDK

and grabs my repo. How is he supposed to know what gems I used? My
first

answer would be - I either document it in the README or I just say
’Install

ChefDK v0.3.5’. Another option would be to manually create a Gemfile
for

everything that I used out of ChefDK and include that along with my
repo?

But in both cases, I’m having to keep some extra piece of information
up to

date with everything I’m using out of ChefDK ( or just telling him he
better

install it ). Am I missing something there?

The second scenario I’m hazy about is when you get into the situation
when

we start drifting between ChefDK versions. Perhaps I haven’t upgraded
my

ChefDK for awhile and you’re on the latest and greatest. What’s
keeping us

in sync, so that we’re using the same versions of Test Kitchen,
ChefSpec,

etc? Or does it not matter, because in general, the differences
between the

gems provided in different ChefDK versions isn’t a big enough concern?

I understand ( I think ), that if I start using 3rd party gems that
aren’t

included in ChefDK, I should be bundle installing them and including
the

Gemfile. I think it’s the two scenarios above that I’m unsure about
and I’m

curious how others are doing this.

I’ve read a few blog posts and the previous mail on the list
http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I
think

I’m still confused enough what the vision/workflow is that I had to
ask.

yo,

ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks’ Gemfiles, or even mega repository
Gemfiles. I don’t think I’ve heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.

One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.

I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn’t take an hour to
compile on smaller rigs :slight_smile:

I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.

hope this helps~

cheers,

–aj

Thanks,

sh