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

Chronological Thread 
  • From: Lamont Granquist < >
  • To:
  • Subject: [chef-dev] Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes
  • Date: Mon, 26 Mar 2012 13:57:46 -0700

My vote is for tighter integration between system config management and application config management. I don't want a whole separate system and separate database and have to replicate state between chef's node data and data bags to the application deployment database and vice versa. I've done that multiple times and it blows. You also always wind up going down this messy road where your apps start to pull in requirements like rpms and config files which are external to just simple "application deployment" and you wind up dropping off config-engine code fragments with your app deploy engine which are picked up and run by your system config management convergence engine (often as root, with devs able to push arbitrary system code, creating huge SOX violations in process that the auditors just never uncover). Ultimately, the right way is to have it integrated. You could have an extra tool that gets added in addition to chef-client, but I think that extra tool is going to wind up with so much of chef-client in it (we need node data and data bags and search, and package resources, and file resources, etc, etc) and will wind up getting called by chef-client, so you might as well do the tight integration to begin with.

I also cut this ticket awhile back which is sort of an inverse problem:


There it isn't that I want to just do one recipe and not run a convergence, its more that i require that every time a convergence is run that a recipe must be executed, no matter how screwed up the rest of the run is (even failures in required recipes are often not fatal to the execution of later recipes, since with proper idempotency those prerequisite recipes will be no-ops the vast majority of the time -- it feels like a sin, but it normally will not seriously bite you, and at the scale of 10,000s of servers it will just be a fact of life to have busted recipes on some servers all the time...).

And if there's any philosophy to chef, I seriously hope it is just getting our jobs done...

On 3/26/12 10:29 AM, Jay Feldblum wrote:
I think the key issue is that:

    application deployment =/= node convergence

Trying to treat application deployment as though it were just another part of node convergence possibly introduces friction into the configuration management, depending on the nature of the application deployment and the nature of the rest of the convergence.

For many people and for many applications, possibly most people and most aplications, this discrepancy is not a problem, and for them, application deploys during chef runs (node convergences) are perfectly fine.

Sometimes the discrepancy is a problem, and I think the best solution sometimes is to have a separate application-deployment mechanism. The application-deployment mechanism is delivered during the node convergence, but application-deployment actions are triggered out-of-band (i.e., not during convergence). A simple application-deployment mechanism is: building & packaging the application on a build server and uploading the built package (slug, deb, lxc-rootfs, etc.) to storage, a script dropped onto each application server during the node convergence that pulls the latest package and installs it, and knife-ssh to invoke the script. As Lusis mentions, Jenkins or similar build systems may also work.

I don't think trying to treat Chef as a glorified script runner is as useful as treating Chef as a declarative final-state convergence engine. Application-deployment may sometimes not fit within the declarative final-state convergence model, and when that happens, it may be wiser not to try to shoehorn it in.

Archive powered by MHonArc 2.6.16.