Those recipes get "loaded" in that order, but the postgresql is the first
one to be "processed":
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Loading Recipe mytardis via
include_recipe
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Found recipe default in cookbook
mytardis
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Loading Recipe build-essential via
include_recipe
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Found recipe default in cookbook
build-essential
...
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Loading Recipe postgresql::client
via include_recipe
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: Found recipe client in cookbook
postgresql
[Sun, 08 Jul 2012 05:14:33 +0200] INFO: Processing
package[postgresql-client] action install (postgresql::client line 37)
[Sun, 08 Jul 2012 05:14:33 +0200] DEBUG: package[postgresql-client]
checking package status for postgresql-client
Why is this? How can I get build-essential to run first?
(I'm doing all this through Vagrant. The target is a local Ubuntu VM. I'm
new to Chef, Vagrant, and Ruby - which may explain a lot.)
I actually would not define a role to build up the state of what your application server looks like.
Not only will this not solve your problem, it also introduces coupling issues between your cookbooks and your chef-repo.
Because roles are stored in your chef-repo and not distributed with your cookbooks, you should keep the logic of what all makes up your application server in a recipe in your applications cookbook. Later, you should include this recipe in a role or directly on the run_list.
A common reason that resources are seemingly run out of order are when you explicitly request they are run at compile time. You should check to see if any of your recipes are attempting this.
In this form, the build no longer does any postgresql step, and proceeds
much further. So, I don't think there are any other "include_recipe
postgresql" lines. Any other ideas?
Are there any workarounds that would force build-essential to run first?
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.
-Peter
On Sun, Jul 8, 2012 at 6:49 PM, Steve Bennett stevage@gmail.com wrote:
Hi Sascha,
Thanks for the suggestion. I tried commenting out the include_recipe that
I quoted before, so:
In this form, the build no longer does any postgresql step, and proceeds
much further. So, I don't think there are any other "include_recipe
postgresql" lines. Any other ideas?
Are there any workarounds that would force build-essential to run first?
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?
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.
-Peter
On Sun, Jul 8, 2012 at 6:49 PM, Steve Bennettstevage@gmail.com wrote:
Hi Sascha,
Thanks for the suggestion. I tried commenting out the include_recipe that
I quoted before, so:
In this form, the build no longer does any postgresql step, and proceeds
much further. So, I don't think there are any other "include_recipe
postgresql" lines. Any other ideas?
Are there any workarounds that would force build-essential to run first?
pg_packages.each do |pg_pack|
package pg_pack do
action :nothing
end.run_action(:install)
end
gem_package "pg" do
action :nothing
end.run_action(:install)
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?
Sascha Bates
| sascha.bates@gmail.com | 612 850 0444 | sascha.bates@skype | sascha_bates@yahoo |
On 7/8/12 6:10 PM, Peter Norton 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.
-Peter
On Sun, Jul 8, 2012 at 6:49 PM, Steve Bennett stevage@gmail.com wrote:
Hi Sascha,
Thanks for the suggestion. I tried commenting out the include_recipe that
I quoted before, so:
In this form, the build no longer does any postgresql step, and proceeds
much further. So, I don't think there are any other "include_recipe
postgresql" lines. Any other ideas?
Are there any workarounds that would force build-essential to run first?
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
