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


Chronological Thread 
  • From: Sean OMeara < >
  • To: Daniel DeLeo < >
  • Cc: Chef Dev < >
  • Subject: [chef-dev] Re: CHEF-3747 - Compile Time Packages
  • Date: Mon, 28 Jan 2013 19:21:43 -0500

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
>



Archive powered by MHonArc 2.6.16.

§