[chef] Re: Feelings on chef


Chronological Thread 
  • From: "Scott M. Likens" < >
  • To: " " < >
  • Cc: " " < >
  • Subject: [chef] Re: Feelings on chef
  • Date: Thu, 6 May 2010 22:33:39 -0700

I will make a short reply,

Configuration management is a puzzle you need to put together.

It changes your work flow; so it takes time for this part to happen in an 
environment that has 0.  You cannot force it, trust me on this one.  Part 
adapting your infrastructure to allow this.  Part adapting your release, 
setup, configuration etc... Chef does not give you a PXE boot server.  But it 
gives you a place to post configure your new server preseed/kickstart.

Chef is a piece to this puzzle, a big piece that can complete the circle with 
time, patience, and hard work.  No chef is not designed for opscode; it is 
designed in mind with all the tools an ops person can and should have at his 
disposal.  

That being said chef is what you make of it.  It adopts heavily in the model 
of TIMTOWTDIT.  Read parts and use parts that you want at first... Then use 
more later... And most importantly do it how you want to... Not how someone 
else tells you to... Take your path.

Btw, sorry for the late response... As usual

Sent from my iPad

On May 4, 2010, at 4:59 AM, Marcus Bointon 
< >
 wrote:

> I've been investigating chef lately, and it's been a pretty rough ride. The 
> main things I've learned:
> The overall philosophy is great
> Chef's implementation is massively complex - I've found chef harder to set 
> up than most of the entire server deployments I would have it do!
> Despite chef-server's huge infrastructure, it's not the definitive source 
> of configuration - the repo is.
> Mixing of ruby and JSON syntax is confusing
> It will get much more usable once stable packages are out (though of course 
> that depends on chef becoming stable itself)
> Deployment of straightforward recipes and roles is easy in general; 
> configuration for individual nodes is not.
> The part that's most likely to need version control (node configs) doesn't 
> live in the repo.
> The documentation is good on detail (though suffers from obsolescence as 
> chef has changed a lot over time), but lacks a big picture
> It doesn't help that ubuntu's vm-builder is fairly broken at present
> Chef people on irc are very helpful
> 
> I have the feeling that most of chef-server is only really much use if you 
> happen to be building a huge infrastructure for hosting chef, exactly as 
> opscode is, and for everyone else it's just overly complex.
> 
> Not having nodes in the repo and server content being overridden by rake 
> tasks seems to render much of the server pointless (especially the web UI); 
> a folder in the repo for node config and a minimal rest interface talking 
> directly to it (i.e. possibly no database) would probably be sufficient for 
> several thousand nodes. Are there any plans for a chef-server-lite?
> 
> Overall, after 3 weeks of investigation, I don't seem to be much closer to 
> my "10 servers in 10 minutes" ideal, which is really quite disappointing. 
> Now I'm wondering if a simpler approach like pacha would be better.
> 
> Marcus
> -- 
> Marcus Bointon
> Synchromedia Limited: Creators of http://www.smartmessages.net/
> UK resellers of 
> 
>  CRM solutions
> 
>  | http://www.synchromedia.co.uk/
> 
> 
> !DSPAM:4be00c1a126031804284693!



Archive powered by MHonArc 2.6.16.

§