What is the “right” way to deal with this problem? I’m using vagrant and
some boxes come with old versions of ohai that cause failures in the chef
run.
The segment below in build-essentials is the current example.
Older versions of ohai do not provide a platform_family
Is crashing out with nil method error for the packages.each
statement okay or should we silently do nothing or ?
packages = case node[‘platform_family’]
when “debian”
%w{build-essential binutils-doc}
when “rhel”, “fedora”
%w{gcc gcc-c++ kernel-devel make}
when “suse”
%w{gcc gcc-c++ kernel-default-devel make m4} # in SLES there is no
kernel-devel
end
If packages is nil after this case statement what is the correct action to
take?
Ideally, I’d like a warning to pop up like
“Hey, your version of ohai is too old, please upgrade”
If the chef run fails, fine but at least print a useful error message.
'platform_family' is the issue here
and it's used already in many cookbooks
I would recommend adding a step to upgrade ohai automatically, and reload
ohai in case of upgrade. Make this to be a first step at compile time.
On Wed, Jan 23, 2013 at 9:00 PM, Booker Bense bbense@gmail.com wrote:
What is the "right" way to deal with this problem? I'm using vagrant and
some boxes come with old versions of ohai that cause failures in the chef
run.
The segment below in build-essentials is the current example.
Older versions of ohai do not provide a platform_family
Is crashing out with nil method error for the packages.each
statement okay or should we silently do nothing or ?
packages = case node['platform_family']
when "debian"
%w{build-essential binutils-doc}
when "rhel", "fedora"
%w{gcc gcc-c++ kernel-devel make}
when "suse"
%w{gcc gcc-c++ kernel-default-devel make m4} # in SLES there is no
kernel-devel
end
If packages is nil after this case statement what is the correct action to
take?
Ideally, I'd like a warning to pop up like
"Hey, your version of ohai is too old, please upgrade"
If the chef run fails, fine but at least print a useful error message.
--
Vladimir Girnet
Senior Infrastructure Engineer
Tacit Knowledge, Inc.http://www.tacitknowledge.com
On 1/23/13 1:56 PM, "Vladimir Girnet" vgirnet@tacitknowledge.com wrote:
'platform_family' is the issue hereand it's used already in many cookbooks
I would recommend adding a step to upgrade ohai automatically, and reload
ohai in case of upgrade. Make this to be a first step at compile time.
Do you mean automatically upgrading ohai (and chef) in the cookbooks that
need to use platform_family?
Ohai 0.6.12 introduced the attribute, and Chef 0.10.10 introduced the
various methods for cookbooks/recipes to use it. Ohai 0.6.12 was released
in March last year, and Chef 0.10.10 was released in May. So
"platform_family" has been around long enough we've felt it safe to use
for cross platform use in our cookbooks.
Simply reloading Ohai may not be enough. Depending on the cookbook, the
newer methods in Chef for recipes may be required (platform_family?,
value_for_platform_family, e.g.).
I think the right thing to do is let it fail, and leave it up to the user
to upgrade Chef+Ohai, or downgrade/modify the cookbook.
Cheers,
Joshua
On 1/23/13 12:00 PM, "Booker Bense" bbense@gmail.com wrote:
What is the "right" way to deal with this problem? I'm using vagrant and
some boxes come with old versions of ohai that cause failures in the chef
run.
Upgrade the Chef+Ohai versions in the vagrant box and repackage it. You
can do something like this:
% vagrant up --no-provision BOXNAME
% vagrant ssh BOXNAME
vagrant$ wget -O - http://opscode.com/chef/install.sh | sudo bash
vagrant$ rm /tmp/chef*{rpm,deb}
vagrant$ exit
% vagrant package BOXNAME
% rm -rf ~/.vagrant.d/boxes/BOXNAME
% vagrant box add BOXNAME package.box
Depending on how Chef was installed on the box, you may need to do
something else (package upgrade, gem install, etc). If it's so old it
doesn't have platform_family, I'm sure it isn't the "omnibus" package,
which is what the wget command above will install.
If packages is nil after this case statement what is the correct action
to take?
Ideally, I'd like a warning to pop up like
"Hey, your version of ohai is too old, please upgrade"
As I mentioned in another reply, the versions of Chef and Ohai that have
platform_family are several months old now. The number of cookbooks using
platform_family will only increase.
Alternately, you can use an older version of the build-essential cookbook.
The platform_family support was added in 1.1.0, so you would have to use
1.0.2.
Cheers,
Joshua
I guess I didn’t phrase my question well. Once I figured out what was
happening, the solution was straightforward. However, this is a usability
problem. Why did I have to spend any time digging to find out why this
cookbook was failing?
There should simply just be the equivalent of
gem ohai ‘=> 0.10.12’
How do you specify that in a cookbook?
If Vagrant is how you learn chef, there will be back level boxes.
Especially as the transition to Chef 11
moves forward.
Mysterious errors for stuff that is supposed to “just work” is not the way
to win friends.