- From: Lamont Granquist <
- To: <
- Subject: [chef-dev] Re: Re: Re: CHEF-3747 - Compile Time Packages
- Date: Mon, 28 Jan 2013 17:45:10 -0800
there were some uses cases in the cookbooks previous where at
compile-time gems were being required. a lot of the cookbooks
have been refactored so that not_if/only_if blocks that use gems
now lazily require the gem and other instances of lazy loading --
the wordpress cookbook used to be a notorious offender which just
did a requires 'mysql' right up front in compile-time. i think it
was felt that it was easier to make installing a chef_gem and then
requiring it to JustWork(tm) rather than having to refactor
requires into evaluation-time blocks.
looking at the cleanup that has been done in the cookbooks it's
possible that this is really an anti-pattern and that the work
should have been put into fixing the cookbooks instead. one thing
to do would be to test all the cookbooks against a patched
chef-client which took out the compile-time forcing of chef_gem
and see what cookbooks are still broken (e.g. aws cookbook is
definitely, but trivially, broken).
On 1/28/13 4:52 PM, Julian Dunn wrote:
I'm with Sean. Just wrote a blog post about how compile-time
execution results in an arms race where you end up just pulling
in more and more things.
On Jan 28, 2013, at 7:21 PM, Sean OMeara <
Compile time modification is a hack that should very
much be discouraged.
I'd rather see something akin to "run stages" where you
the convergence of a recipe before the compile phase of
On Mon, Jan 28, 2013 at 7:02 PM, Daniel DeLeo <
Recently we've been reviewing
CHEF-3747 and wanted to get outside input.
In short, this adds a shortcut
for installing a package at compile time, but
it has an interesting twist: It
creates a corresponding package resource
that will trigger notifications
at converge time where the resource "would
have been" if it had been a
We wanted to hear more from
Chris (the patch's author) about what exactly
he's using this behavior to do. As I understand it,
there are two
1. These packages are prerequisites for gems that are
installed and loaded
2. When installed, additional
resources need to run via notifications.
We also want to hear from you.
This behavior seems quite complex; is it
something you think you would
use? Is the complexity worth the benefit?
I've also come across some
discussions arguing that moving resources to
compile time is an anti pattern.
Personally I think its fine for one-off
hacks, but I'm wary of baking it
deeper into core Chef. Considering that the
compile/converge distinction is
pretty much required to implement
notifications, those obviously
act weirdly when everything gets moved to
compile time. I personally also
think Chef's strict ordering of run list
items and the resource
collection is the best way to get changes made in the
desired order. On the other
hand, this may necessitate splitting cookbooks
into smaller pieces and
sprinkling them across the run_list, which can be
One alternative we've been
discussing here at Opscode is a refactor of the
way that the recipe DSL is
implemented such that you'd be able to prepend
resources to the resource
collection, or insert them at an arbitrary point,
but this isn't something that
would be implemented soon.
Archive powered by MHonArc 2.6.16.