[chef] Re: RE: Re: Getting local yum repositories enabled before other cookbooks demand them in bootstrap


Chronological Thread 
  • From: "Julian C. Dunn" < >
  • To: " " < >
  • Subject: [chef] Re: RE: Re: Getting local yum repositories enabled before other cookbooks demand them in bootstrap
  • Date: Mon, 17 Mar 2014 15:58:20 -0400

On Sun, Mar 16, 2014 at 5:15 PM, Kadel-Garcia, Nico
< >
 wrote:

> Julian, I'm afraid that the relevant yum repositories, namely for packages 
> such as "socat" from EPEL
> and the "Percona-XtreDB-Cluster-server-55" from the the Percona 
> repositories, are not detected as
> available until after the "yum::epel" or more recent "yum-epel" recipes 
> have been successfully run,
> and after the "yumrepo::percona" recipe has been successfully run. But when 
> bootstrapping a system,
> those have not been run successfully yet. the installation recipes for the 
> "mysql" or "percona" or any
> other cookbook  winds up using information from an earlier compilation 
> stage *before* those yum
> repository recipes have actually been run and enabled the 3rd party 
> repositores.

That is what I do not understand. Chef does not "use an earlier
compiled list of available packages". There is no such thing. When you
declare a package resource, during its execution phase both the test
("yum -q <something>") and potentially the action ("yum -y install
<something>") are run.

Everyone who is going on about the "now cookbook" and "having to do
things in the compilation phase" on this thread is wrong, or at least
unnecessarily using the nuclear option without picking up on the fact
that something else is happening under the hood.

To prove that bootstrapping a system, setting up a new Yum repo and
immediately using packages provided by that new repo actually do work,
I fired up Test Kitchen against the MongoDB cookbook
(https://github.com/edelight/chef-mongodb) and ran its
default-10gen-centos-65 suite. This does two things: sets up a new
repo in /etc/yum.repos.d/10gen.repo to MongoDB's repo and then invokes
a package resource to install mongo-10gen-server. This works, in one
fell swoop, out of the box, no extra force required.

In your situation, there is something else going on. Maybe you are
missing a "yum-makecache" somewhere which actually fetches the repo
metadata and makes it available to the 'package' resource?

- Julian

-- 
[ Julian C. Dunn 
< >
          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ;]
gopher://sdf.org/1/users/keymaker/           * compliant!    ;]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]



Archive powered by MHonArc 2.6.16.

§