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
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
davidski@deadheaven.comwrote:
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
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 kevin.nuckolls@gmail.comwrote:
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 <
davidski@deadheaven.com> 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
you can set the gem_binary attribute for gem_package resource to
/opt/chef/embedded/bin/gem to mimic chef_gem , but in converge stage.
i think you can also break down the provisioning to multiple stages, i.e.
apply a base role first, then apply a application specific role, this is
particularly helpful when you have statements in recipes which requires
certain gems to be pre-installed (e.g chef_gem 'foo' then require 'foo', or
a resource that comes from a gem), this way you get to preserve the why_run
and other compatibility without doing any hacks,
regards
ranjib
On Fri, May 2, 2014 at 4:34 AM, David F. Severski
davidski@deadheaven.comwrote:
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 kevin.nuckolls@gmail.comwrote:
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 <
davidski@deadheaven.com> 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