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

[Steven Danna < >]

Hi,

Apologies for duplicates.  It seems I haven't subscribed with my
@getchef.com address yet.

> Chef does not "use an earlier compiled list of available packages".

Unfortunately, I believe it does.  Chef uses a python script [0] to
dump everything yum knows about packages into an internal cache.  The
yum provider has a flush_cache option, however, which can be used to
make sure it reloads the internal cache [1].  Have you tried the
flush_cache options here yet?

Note that even with flush_cache set, you can still run into caching
problems if you have yum itself configured to aggressively cache, but
that usually isn't a problem with a newly added repo.

Cheers,

Steven

On Mon, Mar 17, 2014 at 12:58 PM, Julian C. Dunn 
<
 >
 wrote:
> 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       ]