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

[Lamont Granquist < >]

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:

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

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.