Providing specific version numbers of packages to install with yum


#1

Folks,

My Google-Fu seems to be failing me. I know that Chef has a way to specify versions of cookbooks that have to be loaded, but I can’t seem to figure out how to tell Chef to insist on a certain version (or later) of a particular package to be installed.

The particular case that I have is that Erlang R12B-5 is in the main EPEL repo, but R14B is in the EPEL Erlang repo, and I have both repos installed on a target machine. When I go to install Erlang, it appears that the “yum info” command is being done early in the process before the EPEL Erlang repo has been added, so it comes back and thinks that it should install R12B-5. When yum is finally told to actually install this version, it gets part way through and discovers that the EPEL Erlang repo is also available and has a later version, and then it proceeds to only do a partial install of the R14B stuff that is required.

Needless to say, this leaves the machine very confused and in a non-workable state with regards to Erlang, which keeps RabbitMQ from being installed.

I know that I can run my own repo and include only the versions of Erlang that I want to have in that repo, but until I get to that point I need a way to either tell yum that the EPEL Erlang repo should have more priority over the main EPEL repo, or I need a way to tell yum that it should explicitly install R14B and bail out if it cannot do so. This split version install between R12B-5 and R14B isn’t going to work. In theory, yum should be smart enough to always install the latest version and only that version, but it seems that something is getting seriously hosed.

If all these problems need to be fixed in the yum LWRPs, are the updated cookbooks for that available outside of waiting for Chef 0.10.6? Or am I just screwed?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#2

Do you have the ‘version’ statement in the package resource?

Adam

On Fri, Oct 21, 2011 at 4:18 PM, Brad Knowles bknowles@ihiji.com wrote:

Folks,

My Google-Fu seems to be failing me. I know that Chef has a way to specify versions of cookbooks that have to be loaded, but I can’t seem to figure out how to tell Chef to insist on a certain version (or later) of a particular package to be installed.

The particular case that I have is that Erlang R12B-5 is in the main EPEL repo, but R14B is in the EPEL Erlang repo, and I have both repos installed on a target machine. When I go to install Erlang, it appears that the “yum info” command is being done early in the process before the EPEL Erlang repo has been added, so it comes back and thinks that it should install R12B-5. When yum is finally told to actually install this version, it gets part way through and discovers that the EPEL Erlang repo is also available and has a later version, and then it proceeds to only do a partial install of the R14B stuff that is required.

Needless to say, this leaves the machine very confused and in a non-workable state with regards to Erlang, which keeps RabbitMQ from being installed.

I know that I can run my own repo and include only the versions of Erlang that I want to have in that repo, but until I get to that point I need a way to either tell yum that the EPEL Erlang repo should have more priority over the main EPEL repo, or I need a way to tell yum that it should explicitly install R14B and bail out if it cannot do so. This split version install between R12B-5 and R14B isn’t going to work. In theory, yum should be smart enough to always install the latest version and only that version, but it seems that something is getting seriously hosed.

If all these problems need to be fixed in the yum LWRPs, are the updated cookbooks for that available outside of waiting for Chef 0.10.6? Or am I just screwed?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#3

On Oct 21, 2011, at 6:37 PM, Adam Jacob wrote:

Do you have the ‘version’ statement in the package resource?

For yum, I don’t think so. The only things I have in cookbooks/yum/resources are key.rb and repository.rb. Stripping out the .svn hierarchies, the README.md, any .json files, and all comments in the remaining files, I don’t find many references to the word “version” anywhere in the yum cookbook:

% grep -ir version * | egrep -vi '(.svn|README|.json|:#)'
attributes/default.rb:default[‘yum’][‘epel_release’] = case node[‘platform_version’].to_i
metadata.rb:version "0.1.3"
providers/key.rb: if node[:platform_version].to_i <= 5
providers/key.rb: elsif node[:platform_version].to_i >= 6
recipes/epel.rb:major = node[‘platform_version’].to_i
recipes/yum.rb: source “yum-rhel#{node[:platform_version].to_i}.conf.erb”

Or did I completely misunderstand the question somehow?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#4

On 22 October 2011 15:48, Brad Knowles bknowles@ihiji.com wrote:

On Oct 21, 2011, at 6:37 PM, Adam Jacob wrote:

Do you have the ‘version’ statement in the package resource?

For yum, I don’t think so. The only things I have in cookbooks/yum/resources are key.rb and repository.rb. Stripping out the .svn hierarchies, the README.md, any .json files, and all comments in the remaining files, I don’t find many references to the word “version” anywhere in the yum cookbook:

% grep -ir version * | egrep -vi '(.svn|README|.json|:#)'
attributes/default.rb:default[‘yum’][‘epel_release’] = case node[‘platform_version’].to_i
metadata.rb:version "0.1.3"
providers/key.rb: if node[:platform_version].to_i <= 5
providers/key.rb: elsif node[:platform_version].to_i >= 6
recipes/epel.rb:major = node[‘platform_version’].to_i
recipes/yum.rb: source “yum-rhel#{node[:platform_version].to_i}.conf.erb”

Or did I completely misunderstand the question somehow?

Indeed.

yum_package “someshit” do
version "1.2.3-whatever"
end

–AJ

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#5

On Oct 21, 2011, at 10:25 PM, AJ Christensen wrote:

yum_package “someshit” do
version "1.2.3-whatever"
end

I can confirm that this form works:

yum_package “erlang” do
version "R14B-03.3.el5"
end

However, that ties us to a specific version of Erlang, which I’d rather not do as a part of the recipe. I’m sure I could over-ride this from a role, but is there a more elegant way to specify that we need something greater than version R12B, but without tying us to a specific version & release?


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#6

There isn’t a semantic to do version constraints on package resources

However, you could assign it through a node attribute. Then when you have vetted a new version for your infrastructure you can modify the version. I suggest setting a base version in the cookbook’s attributes file as so:

default[‘erlang’][‘version’] = “R14B-03.3.el5”

Then you can modify through a role:

name "erlang-service"
default_attributes(
‘erlang’ => {
‘version’ => “R14B-03.4.el5”
}
)

Replace “erlang-service” with the appropriate name of the service that uses Erlang, e.g., rabbitmq.

On Oct 24, 2011, at 8:55, Brad Knowles bknowles@ihiji.com wrote:

On Oct 21, 2011, at 10:25 PM, AJ Christensen wrote:

yum_package “someshit” do
version "1.2.3-whatever"
end

I can confirm that this form works:

yum_package “erlang” do
version "R14B-03.3.el5"
end

However, that ties us to a specific version of Erlang, which I’d rather not do as a part of the recipe. I’m sure I could over-ride this from a role, but is there a more elegant way to specify that we need something greater than version R12B, but without tying us to a specific version & release?


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#7

On Oct 24, 2011, at 10:08 AM, Joshua Timberman wrote:

There isn’t a semantic to do version constraints on package resources

However, you could assign it through a node attribute. Then when you have vetted a new version for your infrastructure you can modify the version. I suggest setting a base version in the cookbook’s attributes file as so:

default[‘erlang’][‘version’] = “R14B-03.3.el5”

Then you can modify through a role:

name "erlang-service"
default_attributes(
‘erlang’ => {
‘version’ => “R14B-03.4.el5”
}
)

Replace “erlang-service” with the appropriate name of the service that uses Erlang, e.g., rabbitmq.

I’ll give this a shot, but it seems that we still will have a timing issue here. I’ve gone through this a couple of times, and I’m convinced that the issue I’m running into is that the EPEL Erlang repo is not being fully installed before yum goes to install the correct version of the Erlang package. Most recently when I tried this (hard-coding a specific Erlang version as part of the recipe), I got this error:

FATAL: Chef::Exceptions::package: yum_package[erlang] (erlang::default line 35) had an error: Version R14B-03.3.el5 of erlang not found. Did you specify both version and release? (version-release, e.g. 1.84-10.fc6)

However, I know that if I run chef-client again on this node, everything will install fine. I’m wondering what is the proper way to ensure that the EPEL Erlang repo is fully installed before trying to do the yum install of the package – put the yum install in a ruby_block, to force it to be as late in the process as possible? Is there a way to cause the install of the EPEL Erlang repo to happen a lot earlier in the process?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#8

I’ll give this a shot, but it seems that we still will have a timing issue here. I’ve gone through this a couple of times, and I’m convinced that the issue I’m running into is that the EPEL Erlang repo is not being fully installed before yum goes to install the correct version of the Erlang package. Most recently when I tried this (hard-coding a specific Erlang version as part of the recipe), I got this error:

FATAL: Chef::Exceptions::package: yum_package[erlang] (erlang::default line 35) had an error: Version R14B-03.3.el5 of erlang not found. Did you specify both version and release? (version-release, e.g. 1.84-10.fc6)

However, I know that if I run chef-client again on this node, everything will install fine. I’m wondering what is the proper way to ensure that the EPEL Erlang repo is fully installed before trying to do the yum install of the package – put the yum install in a ruby_block, to force it to be as late in the process as possible? Is there a way to cause the install of the EPEL Erlang repo to happen a lot earlier in the process?
Yes, use the run_action trick. Using apt-get update as an example that I’m familiar with:

execute "apt-get update" do
  action :nothing
  # !!! If you put the run_action inside the block, put it last
  run_action :run
end

This will probably fix your problem. Chef has some internal caching of yum info that could be involved as well, but it’s had a lot of updates recently so I’m not sure of the best procedure to flush it anymore.

HTH,


Dan DeLeo