[chef] Re: Re: Re: Re: How to control the order that Chef (solo) executes resources?


Chronological Thread 
  • From: Steve Bennett < >
  • To:
  • Cc:
  • Subject: [chef] Re: Re: Re: Re: How to control the order that Chef (solo) executes resources?
  • Date: Mon, 9 Jul 2012 11:20:31 +1000

On 9 July 2012 09:10, Peter Norton < " target="_blank"> > wrote:
Is it possible that your recipe mytardis::postgresql forces
installation of the client at compile time?  This is a trick that's
often used to make sure that some resources are available early in the
run, and which can make things appear to happen in an order that is
different from what's described in the cookbook, but in fact it is
what the cookbook author intended.


Ok, thanks, that looks like the problem.

----
pg_packages.each do |pg_pack|
  package pg_pack do
    action :nothing
  end.run_action(:install)
end
----


Seems I'm not the first one to hit this issue either:

postgresql::server (in cookbooks, rather than site-cookbooks) is straight from Apache I think:

Doing the same thing on build-essential (that is, adding end.run_action(:install)) works - or at least, fails later on in the build :)

Sascha wrote:
>There's probably a good reason for this.  You could change it so it's not running at compile time but that will probably break something else that assumes it's already available. 
>Is this breaking your build-essentials install or are you just trying to figure out why it's running out of the order you assumed?

The problem is that the Postgres client seems to need to build something using C tools, and they're not installed by default on the minimal Ubuntu distribution I'm using (from Vagrant). So, installing the client *before anything else* doesn't work - I need to install build-essential even earlier.

Anyway, I guess I have a functional workaround for now - but I'm sure I'll be back soon with other issues :)

Steve





Archive powered by MHonArc 2.6.16.

§