[chef-dev] Re: Re: Re: Supported versions

[Daniel DeLeo < >]

On Sunday, June 1, 2014 at 3:32 PM, Ranjib Dey wrote:
> many reasons:
>  
> 1) Native gems: i use linux as my laptop(ubuntu 14.04), rest of team uses 
> OSX. integration tests are also on lxc (in CI), out side CI both lxc & 
> vagrant is used. lxc deps are linux specific, which we address using 
> separate Gemfile or groups inside a Gemfile. all these details are captured 
> in git. I dont know how i'll address that with ChefDK.
You can use ChefDK alongside your current ruby env if you’d prefer to do 
that. Or, you can let ChefDK be your ruby environment. In either case, you 
can keep using bundler for anything you want to use outside of ChefDK.
  
>  
>  
> 2) ChefDk being a system installer will require any installation script 
> (provisioning developer machine for example) to have root privilege for 
> execution. Currently its same as any other ruby project (bundle install). 
> all our Gemfiles(s) have locked ruby versions (that reflect production) and 
> I dont enforce any constrain on what ruby version manager developers should 
> use.  
>  
> 3) When we hit any bug in our chef tooling ( chefspec, berks, chef itself), 
> Gemfiles allows us to test and fix those bugs against our patches. All of 
> this is captured in out feature branches in our repo (which revert back the 
> Gemfile to point to GA releases). This will be very complicated with chefdk 
> (where we'll capture the gem versions of chefdk?).
We’re not there yet, but the goal is to continuously deliver ChefDK. At the 
moment you need a separate ruby environment if you want to develop, but as 
soon as your patch gets in, you should have a supported release of it the 
next day.
  
>  
>  
> 4) lot of our dependency cookbooks (e.g. heavywaters, lusis' etc) uses 
> librarian. I still use berks., but I am keen to get rid of celluloid from 
> non-jruby apps. And if that happens I have to modify chefdk.
You can keep using librarian either by installing it to ChefDK (run `chef gem 
install` in your shell) or in a separate ruby environment.
  
>  
>  
> 5) if rvm is installed, then GEM_PATH, and GEM_HOME cant screw with any 
> ruby scripts, even if it has hardcoded exact omnibus ruby path. i had hit 
> this with chef-omnibus. the only bulletproof way to address this was to 
> invoke ruby scripts with env -i (i dont know of any better solution :-( ). 
> till recently chef had a bug (PATH) which would inhibit invoking env -i 
> chef-client , but now thats fixed. So even with all other system rubies i 
> can now invoke any ruby script (including chef) with env -i , as long as it 
> has a valid ruby in its #! line. With this, gem management is now really 
> trivial and decoupled (use a shared gemset or have local .bundle & 
> Bundler.setup as part of the scripts). this reduces the incentive to use 
> chefdk (in fact any omnibus installation)
Appbundler fixes this for the ChefDK app, chef-client/knife, berks, and TK by 
making the ruby executables unset those variables. It looks like this: 
https://gist.github.com/danielsdeleo/8a5af647ef2c0ff2b23c See also: ;
https://github.com/opscode/appbundler/
  
>  
>  
> 6) Chef (11.8) is already available on ubuntu 14.04 , with ruby 1.9 & 2.0. 
> So we can do a mixmode with system wide ruby+chef from apt repo, and 
> individual scripts having their own stuff. ruby tooling has changed a lot 
> on ubuntu, its not like 2 years back when we all were stuck with 1.8.7 even 
> if 1.9 was out.
You can still have a “mix mode” if you want, ChefDK just provides a few more 
executables in the omnibus package. If you want ChefDK to be your one true 
ruby environment, that’s an opt-in thing.
  
>  
>  
> 7) after vagrant went omnibus, i had to rewrite lot of scripts only because 
> vagrant's plugin model was changed. I fear what will happen if chefdk 
> introduces something like that,

We’re not taking away the ability to use Chef as a library, and in fact we’d 
like to double down on the library-ness of chef-client code by extracting 
anything ChefDK the app uses to a separate gem (or gems). That’ll allow you 
to pull in just a subset of the chef code (and deps) that you need for a 
given task.
  
>  
> these are some of the immediate concern i have, and i think im not the 
> intended user here (correct me if im wrong),
>  
> But i do understand that building berks is time consuming now (16 min on my 
> laptop), and might be more difficult on windows. ChefDK will definitely 
> shine there. In fact anyone, who wants to use a single version of chef for 
> really long time will be better off with chefdk.  
>  
> best
> ranjib

Hope that clears some things up. The most important bit being that ChefDK 
doesn’t have to be your only ruby environment if you’re happily doing stuff 
with a different ruby environment, and the appbundler executables mean that 
things should work even if you want to use rvm for other ruby tasks.


--  
Daniel DeLeo