Posts on Cloud,DevOps, Citrix,VMware and others. Also tracking my Continuous learning from Wintel to open source and development.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.

Sunday, February 22, 2015

Chef 12.1.0 chef_gem resource warnings [feedly]

Apologies for the new Warn SPAM

Chef 12.1.0 will be released shortly and commits have been merged to master which will result in the following warning banners being output for all uses of the chef_gem:

[2015-02-17T23:59:35+00:00] WARN: chef_gem[fpm] chef_gem compile_time installation is deprecated [2015-02-17T23:59:35+00:00] WARN: chef_gem[fpm] Please set `compile_time false` on the resource to use the new behavior. [2015-02-17T23:59:35+00:00] WARN: chef_gem[fpm] or set `compile_time true` on the resource if compile_time behavior is required.

Sorry for the annoyance, but this is being done for a good reason. Making these warnings go away will also be substantially easier than the CHEF-3694 errors.

Background

When Omnibus was first created we needed a way to target installing gems into the omnibus repo so that chef could internally use it and installing them into the base system, so the chef_gem resource was created. Back then we didn't know any better than throwing require "mysql" directly into recipe code and since the require was compile-time it would always blow up with LoadError if the installation of the chef_gem was delayed until converge time. We decided to bake into the resource that chef_gem would always install at compile time to avoid this problem.

Now, fast forward 2 or 3 years and best practice is to make require lines more lazy. Library cookbooks that use chef_gem's should expose LWRPs and the require should occur in the provider code which moves it to converge time. That eliminates the need to install the chef_gem at compile time. We now somewhat regret the choice that was made in forcing chef_gem to run at compile time.

And this causes issues where if you're doing things right and don't require gems at compile time you're still forced to install chef_gems at compile time. If you are installing a native gem this forces build-essentials to be installed at compile time. If your native gem depends on zlib or libxml2 or libxslt then you need those libraries installed first at compile time and now those cookbooks need compile_time flags to get exposed. It creates a bit of a race to install things at compile time where there is no longer any need to do so.

Changes in Chef 12.1.0

The chef_gem resource gets a compile_time boolean property in 12.1.0 so that compile_time false will shut this behavior off. This is now the recommended setting. In Chef 12.1.0 the default is still to install at compile_time so there is no breaking change being shipped in Chef 12.1.0.

However, the intent is to change this default. In order to make that future transition less painful, the warning is letting you know that you must be explicit about if you want your chef_gem resources to run at compile time or converge time. There are actually two switches which can be used.

Per-Resource Flag

This will be a bit tedious since it requires updating every chef_gem resource, but to adopt the new behavior you can just add compile_time false like:

chef_gem "aws-sdk" do compile_time false end

If you wind up with your recipes throwing a LoadError somewhere (and you should test with fresh builds or manually delete the gem out of your omnibus install in order to surface this problem) then you may need compile_time true:

chef_gem "aws-sdk" do compile_time true end

Global Config Flag

A global Chef::Config[:chef_gem_compile_time] flag was added which can be used to globally switch behavior and it has effects on the warnings. It has three different values:

nil: this is the current default and results in all the spammy warnings

false: this will be the future default, it removes ALL warnings, but will flip the behavior of chef_gem and some recipes may fail

true: this maintains the current default behavior, suppresses the individual warnings, but WARNs once per chef run that this is set to true

So, nil is for spammy warnings, false is for early adopters (some cookbooks certainly will break, those will need compile_time true flags on their chef_gem resources or will need to get fixed), and true means that you're too busy to care, but the tradeoff is that when the default does change at some point in the future you will likely get broken at some point in the future when that default changes AND when you stat pulling cookbooks that assume that as the default.

Community Cookbooks

All the community cookbooks will need fixes to suppress these warnings. Since they require backwards compatibility with prior Chef versions, the preferred PR to submit will look something like this:

chef_gem "aws-sdk" do compile_time false if Chef::Resource::ChefGem.method_defined?(:compile_time) end

Again, Sorry

Sorry for the Warn SPAM but it's for a good cause. The ultimate goal is much less need to force anything to compile mode, which is vastly more annoying.