Thank you very much for the detailed explanation of your solution. I was
afraid that this would come down to something I’d have to handle outside my
standard chef runs. As a newish chef user, my primary use case is
configuring dev and POC boxes either locally or on AWS via Vagrant, with
provisioning via chef-solo. Baking my own images is an added layer of
complexity and learning I was hoping to avoid at this stage, though that
may not be possible.
It sounds as if it may be possible to change the use of chef_gem to
gem_package (or just package) to get the execute order to happen later in
the converge phase. That does mean that the gem gets installed globally
rather than just for the chef client, but that may be the path of least
resistance for this project.
Again, thanks for the walk through on how you’re approaching provisioning.
It’s very useful!
On Thu, May 1, 2014 at 9:19 PM, Kevin Nuckolls firstname.lastname@example.org:
The quick fix is to make sure apt is updated before these recipes run
during compile phase instead of convergence phase.
You may not be willing to go all the way down the road I went down to
solve this problem and a host of similar problems just like it but I’ll go
over it. Basically, I started using Packer to create my very own basebox
image and I completely restructured our basebox recipes to be separated
into an “image” recipe and a “postlaunch” recipe. After two years of
headaches with apt here and there I have come to the conclusion that it
just solves a lot of problems by removing apt-get update from the chef-run
completely and making sure that it’s up to date in the image before the
run. For the specific example of fog being installed at compile time
instead of converge time I just made sure in my basebox “image” had fog and
all the libxml2 / nokogiri dependencies installed correctly. That way when
other cookbooks expect them, they’re already there. In my experience this
lessens the number of apt-based edge cases to debug when you just want to
slam out a wrapper cookbook.
There is one exception. If a recipe adds a repository, the apt cookbook
can / should be notified to perform an apt-get update. Personally, I’d
prefer for that to happen exactly once. If nodes start to fail because
their apt is old, or it’s just time to do an apt-get upgrade then it’s
probably actually time to shoot those nodes in the head and roll out new
ones on freshly cut baseboxes. That or you run sudo apt-get update with
knife ssh and re-run chef client and you’re back in business.
This is just my current philosophy on the matter. I haven’t been all the
way down the rabbit hole to see where this particular paradigm breaks down.
That said, thus far I greatly prefer it to trying to always start from a
vanilla ubuntu install.
Hope this helps.
On Thu, May 1, 2014 at 10:31 PM, David F. Severski <
I’m getting some weirdness with the elasticsearch cookbook and finding
some weirdness with the ebs recipe. When I include this recipe in my
Chef-Solo V11 run list, I’m seeing the ebs recipe, specifically the fog gem
installation, happen before recipes that occur in my run list. This is
problematic as I need the apt cookbook to run and update my repos. Having
these out of date causes the fog install to fail.
I suspect this is relating to execution order, but I’m not clear on how
to resolve this, short of baking my image to have more current repos at
boot time (yuck). Can someone confirm my interpretation and hopefully
provide some guidance to work around this problem?