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

[Lamont Granquist < >]

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:

" 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.

http://www.juliandunn.net/2013/01/23/when-application-and-library-cookbooks-fail/

- 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.

-s

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.

http://tickets.opscode.com/browse/CHEF-3747

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

constraints:

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

awkward.

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.

Thoughts?

--

Daniel DeLeo