[chef-dev] Re: Re: Re: Re: Re: Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes

[John Vincent < >]

On Mon, Mar 26, 2012 at 12:43 PM, Joe Williams 
<
 >
 wrote:
> Hey gang,
>
> Finally getting around to chiming in on this, as the client of Heavywater
> that commissioned them to build this feature (to some of you this will be of
> no surprise :) here are my thoughts and experiences.

Honestly I'm surprised that it was you ;)

>
> Here's the main idea, we want regular, periodic converges to deal with all
> aspects of the system except for specific applications. Our application
> deployments are surprisingly similar to the idea of a Heroku slug.
> Everything the application needs bundled up in a tidy package. Any change to
> the that package is a new version of the application, this includes
> configuration changes. Not to get metaphysical but a configuration change is
> just the next iteration in a long line of changes in the life of an
> application. A configuration change changes what the application *is* just
> like changing code but we rarely version them that way. As a result we only
> want changes to configurations to happen on deploy, we never want our
> configs to change to happen due to a search index update when a new node
> comes online. Search is awesome and I want to make good use of it but we
> deploy often enough that it can wait until we ship more code and tell chef
> to update the config. So the end result is a steady state run_list that
> everyone can expect to keep the system in check and updated and then when
> developers do their deploys a single application recipe chef-client run with
> only that recipe in the run_list. Additionally, as someone else mentioned,
> this has the added benefit of avoiding any issues, bugs, whatever that my
> occur in recipes before/after in the run_list. I want my developers to
> deploy as often and as quickly as possible, they won't do that if they run
> into bugs I wrote in recipes causing their deploys to fail.
>

In all honestly, this feels like a case where doing the deploys with
Chef feels like it doesn't fit. I mean I've seen the deploy code
you've written before and it's awesome.
Does any of the application configuration get handled by chef at all?
I'm guessing not. Or are there system level configurations that impact
HOW the application is launched (env vars or whatnot?). I mean I get
that Chef manages the layout of base bits on disk (and maybe the
initial structure needed by the applications)?

Honestly, this is why at the previous company we used Jenkins for all
the deploys. We had hooks into our jobs to get information from Chef
(in our case via Noah - not acceptable for you guys obviously).
Initial bootstraps of new nodes would pull down the latest released
code artifact (tarball) so that it could come up ready to serve but
those artifacts were created by Jenkins.

> In the end this is an attempt at isolation of recipe converges and
> consolidation of any application changes to only deploy time. If there is a
> better way lets do that but this seemed like the least invasive and lowest
> risk to get the functionality I wanted.
>
> -Joe

I totally see the need but at some point it feels like shoehorning in
to Chef. Maybe adding it provides enough flexibility to stave off the
need to "Herokuize" your world. I'm a big fan of either doing
something all the way with Chef or using a tool that's a better fit.
If application deployments can't afford the whole Chef run (and I can
totally see why that might be the case), then I wouldn't use Chef to
do them.

Thanks for the clarification though. I do have a much better picture 
internally.

> On Thursday, March 22, 2012 at 3:50 PM, Christopher Brown wrote:
>
> Peter,
> Good point, and I'd echo the same. We are working internally on design for
> just that feature (ad-hoc push execution of partial / alternative run lists)
> and want to share our ideas with the community once we have a better handle
> on it.
>
> -Chris
>
> On Mar 22, 2012, at 3:28 PM, Peter Donald wrote:
>
> Hi,
>
> It seems like this is an attempt to jury-rig something onto the chef
> model rather than changing the model. It seems like the use case is
> actually adhoc execution of commands/resource installation using the
> chef syntax? If so why not add the ability to distribute a one-shot
> command to chef clients when needed. Then these application deploys
> and/or apt-get upgrades or whatever could be run through this system
> and regular infrastructure maintenance can continue to use the
> existing approach. I think trying to merge the two approaches may lead
> to a bit of complexity when adopting chef.
>
> The one place where I can see a useful to have an include/exclude is
> in the resolution of cookbook dependencies. I can quiet easily see
> that it is unnecessary to have a apt cookbook in a chef server if you
> are only deploying to redhat infrastructure. It would be nice to add
> an exclude and be done with it.
>
> --
> Cheers,
>
> Peter Donald
>
>