[chef-dev] Re: Re: Re: CHEF-3747 - Compile Time Packages

Chronological Thread 
  • From: Sascha Bates < >
  • To: Julian Dunn < >
  • Cc: Sean OMeara < >, Chef Dev < >
  • Subject: [chef-dev] Re: Re: Re: CHEF-3747 - Compile Time Packages
  • Date: Mon, 28 Jan 2013 19:03:02 -0600

Sascha Bates | "> | 612 850 0444 | | |
Almost every time I've arranged to run installs/configs at compile time, I usually find that I made a mistake somewhere along the line in my work and can usually unravel a boatload of compile time activities once I've identified the error.  I do believe there are valid reasons for doing it sometimes, but as Chef has matured and my programming skills along with it, these are def exceptions and not rules.

I don't want to belittle anyone's issues that they are solving with compile-time because I know I have been frustrated and used that method to solve problems, but I think that generally some careful coding can address most compile time issues. I think that what we often see is people generously contributing their internally developed cookbooks that were used to solve specific problems but are not always entirely universal in application.  Maybe we can make a community workshop/hackday where we try to take some of the contributed cookbooks and work on making them models of ideal behavior?  There might even be an additional readme section that elaborates on the problem that was solved with a hack and how the contributor solved it long-term more gracefully as a chef programming lesson as well. "Advanced Chef Problem Solving" or something :)


On 1/28/13 6:52 PM, Julian Dunn wrote:
" type="cite">
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.


- Julian

Sent from my smartphone. Sorry about any typos.

On Jan 28, 2013, at 7:21 PM, Sean OMeara < "> > wrote:

Compile time modification is a hack that should very much be discouraged.

I'd rather see something akin to "run stages" where you could force
the convergence of a recipe before the compile phase of another.


On Mon, Jan 28, 2013 at 7:02 PM, Daniel DeLeo < "> > wrote:
Hi Chefs,

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 converge-time resource.

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
via chef_gem;
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.


Daniel DeLeo

Archive powered by MHonArc 2.6.16.