[chef] Re: Re: chef_gem execution order

["David F. Severski" < >]

Kevin,

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!

David

On Thu, May 1, 2014 at 9:19 PM, Kevin Nuckolls < " target="_blank"> > wrote:

Hi David,

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.

Best Regards,

-Kevin

On Thu, May 1, 2014 at 10:31 PM, David F. Severski < " target="_blank"> > wrote:

Ohai, chefs!

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?

Graci!

David