
Chef 11 released - tphummel
http://www.opscode.com/blog/2013/02/04/chef-11-released/
======
lifeisstillgood
Can someone explain to me the benefits of moving to chef or puppet as opposed
to say my current approach of writing deploy scripts in pythons fabric
(basically ssh and file operations library)

I have even used Puppet but I could not get over the feeling that it is more
complex than I would imagine for small end users (I have managed upto 40
servers with my libraries - it seemed quite feasible to double that. Maybe
it's me but 100 servers sounds a lot and is manageable (deployment wise) with
controlled scripts.

~~~
bithive123
Configuration management is one of those things where you reap most of the
benefit just by doing it, not by doing it with a particular tool.

That said, I prefer Puppet because its abstractions make more sense to me, and
are pretty easily extended using Ruby.

Puppet is also trivial to bootstrap (at least on Debian). Unlike other Ruby
stacks, I can install it using the package manager and be up and running in no
time. With Chef you have to maintain additional services like CouchDB and
RabbitMQ.

The real reason not to use ad hoc scripts or a tool you wrote yourself is that
things like cfengine, Chef, and Puppet are maintained and used by communities
-- your successor(s) will thank you.

~~~
viraptor
> With Chef you have to maintain additional services like CouchDB and
> RabbitMQ.

And care about a lot of dependencies. Installing chef-server on a fresh ubuntu
quantal:

    
    
        0 upgraded, 444 newly installed, 0 to remove and 58 not upgraded.
        Need to get 280 MB of archives.
        After this operation, 775 MB of additional disk space will be used.
    

Of course a lot of that is due to how ubuntu packages java, but still...
that's quite a lot of software to care about.

~~~
jtimberman
With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ
is still there. Opscode provides a single package with _everything_ above libc
required to run the server.

<http://www.opscode.com/chef/install> \- "Chef Server" tab.

If you'd like to build your own:

<https://github.com/opscode/omnibus-chef> <https://github.com/opscode/omnibus-
software> <https://github.com/opscode/omnibus-ruby>

Cheers, Joshua Timberman, Technical Program Manager, Opscode, Inc.

------
druiid
Congratulations to the Chef crew! Here's one thing I still am wondering
though, being a relatively heavy Puppet user now. What are the big benefits to
using Chef, or would it be mostly just admin choice here? When I was
originally deciding upon a CM system I looked at Puppet, Chef and Salt and
decided that Salt was too new (even though I know Python), Chef declared
everything in Ruby and I had no intention of learning Ruby just to generate
server configurations and then finally Puppet, which I found (personally) to
be simple to use/learn and didn't require me to directly learn Ruby unless I
need to extend the 'language' of Puppet.

~~~
pjungwir
Theoretically you can use Chef without knowing Ruby, since if you're using
pre-existing cookbooks you can just say what to install by listing the recipes
in JSON format.

But practically speaking I'd say Ruby is essential. It'd be a disaster trying
to use others' cookbooks without being able to read the recipes, and almost
certainly you'll want to do something they don't cover.

On the other hand, perhaps Chef is an _opportunity_ to learn Ruby? Certainly
you can be productive with a very superficial understanding of the language,
so you could get started pretty quickly. And a Chef recipe is about the
flattest, simplest code imaginable.

~~~
druiid
Well, if you're using Chef and just using pre-existing cookbooks I'd say you
take away 90% of the power of a CM system. So yeah, probably using Chef you
have to know Ruby, full-stop.

For admins whom have a history with Ruby that's not a huge request, but at the
same time I question how useful it is to basically require an admin to code in
a particular language to build system configurations (And that is the one
thing that drew me to Puppet... that while it had a 'language' it wasn't
REALLY a language, more a template syntax).

I can certain agree with the idea of using Chef as an opportunity to learn
Ruby and when the day comes I have some spare time to start then it might be a
good place to begin using it.

Really though beyond the language aspect, I was wondering what the feature-set
that Chef offered over Puppet, things like structural decisions like how nodes
are managed, node removal (kind of a sore spot in Puppet right now), etc.

~~~
pjungwir
I don't know enough about Puppet to compare them, but the impression I got
from reading several comparisons a year or two ago was that Puppet had a more
mature community and hence better cookbooks, while Chef was better suited to
"dynamic" responses, like adding nodes in response to high load. So perhaps
Chef has better removal abilities.

~~~
druiid
Well, the community for Puppet is good, but oddly there are many modules (what
Puppet calls a 'cookbook') missing for some relatively trivial things. For
instance, I have written about 10 modules now for various system
utilities/resources/services now which didn't exist as of yet, or at least
were very... ahem... not good. For example, I've basically re-written my own
nginx module because the ability to add reverse-proxy caching to server
entries didn't exist even in the Puppet Labs nginx module (really, this is a
thing)!

------
seyz
Impossible for me to join the opscode website. Maybe HN has crashed the web
server due to the number of users? :)

~~~
esad
What's even worse is that the install script at
<https://www.opscode.com/chef/install.sh> is also unavailable, which is the
default way of getting chef installed onto newly provisioned server.

~~~
chrislaco
Yeah. That's a fail. Pretty much killed my afternoon.

------
tszming
My overall experience with Chef isn't that great, because seems to me their
team didn't response to users'issue seriously.

E.g. I have reported a bug [1] half year ago that the chef-server failed to
start automatically when your server restart, still mark as `Unresolved` and
no official answer from chef.

I think when your server startup script failed to work on a major distribution
like Ubuntu, it should be considered as critical, right?

[1] <http://tickets.opscode.com/browse/CHEF-3204>

~~~
btmspox
I'm sorry you feel that you didn't have a good experience.

As one of the original Chef contributors before Opscode, and then becoming one
of the lead people working with the open source community for Opscode, the
vitality of the open source Chef project is very important to me. However,
Opscode's support for all of our open source projects also hinges on the
company being successful enough to continue to do so. Thus, a balance must be
struck.

Opscode doesn't respond to every ticket on that open source tracker, just like
we don't write all of the code in the open source project. I personally try to
at least see every issue, but with over 1.8 million installs of the Chef gem
alone, there are a lot of users out there. If you want a guaranteed response,
we do have various paid support plans which will provide you with that, but it
doesn't come for free because we have to pay the people who research and write
those responses.

There are multiple ways to install the Chef 10 Server and many ways to start
the processes. We have tried to support the most popular, and I think most
people have found success. We're proud that we can do things like release our
rewrite of the Chef Server in erlang back to open source. We want it to be
easy for people to use Chef. We initially wrote it to make our lives easier,
and we want your lives to be easier too. That's why the Chef 11 Server ships
in our Omnibus packaging, which provides a running Chef Server in three
commands or less.

~~~
tszming
Hi btmspox,

Firstly, thanks for your reply and your works on chef. I really appreciate it.

I think there is a difference between people who want free support & people
who document a bug of a opensource project clearly in the hope of to improve
the quality of that project - I hope I am in the latter case.

My reported issue can be easily fixed with some hacky workarounds, so I didn't
bother with it and move on (As you can see I have never comment on that
ticket). However, I still decided to create that ticket because I think the
issue is easy to reproduce and will affect a lot of new comers to chef.

The issue is confirmed by others as well, one awesome commenter Florin Mihaila
even provided a very detail analyse and solution to the issue.

For me, I would prefer if you can close the ticket if you think it is invalid,
or mark as don't fix if resource is not allowed, rather than leaving as open
and unanswered.

Of course, this is your project so I can't disagree with your preference,
thanks anyway :)

~~~
btmspox
Always appreciate bugs being filed. I did a little pondering on the ticket the
other day. Since we're using update-rc.d, we're likely talking about debian
package install, which means that we could probably set the defaults correctly
with update-rc.d, someone just needs to do the research and patch the init
scripts or the debian packaging. So it's best for the bug to be open.

[http://www.debian.org/doc/debian-policy/ch-
opersys.html#s-sy...](http://www.debian.org/doc/debian-policy/ch-
opersys.html#s-sysvinit) [https://github.com/opscode/opscode-
packages/tree/master/debi...](https://github.com/opscode/opscode-
packages/tree/master/debian/chef/debian)
[https://github.com/opscode/chef/tree/10-stable/chef/distro/d...](https://github.com/opscode/chef/tree/10-stable/chef/distro/debian/etc)

------
zem
the combination of erlang backbone + ruby nodes is a wonderful way to write
distributed systems. i've put in my time rolling my own when a single-node
system needed to go distributed, and today i'd pay the up-front cost of
integrating either erlang or a message queue as soon as i added the second
node; these things invariably have to scale up more than you'd expect, and
your homegrown system will almost as invariably fall over and die when you can
least afford it.

------
makerbreaker
Another thing I think helps to explain how beneficial a good configuration
management system is, especially if you have a good deal of systems, is to
think of the servers as part of a botnet, and chef as the command and control.

------
pwelch
I started with Chef around version 10.4. It's really amazing to see how far
Chef and the community have come since then. Keep up the awesome work Opscode!

------
Tomino
I haven't try Chef yet, but it seems like it has some advantages, I should
give it a try!

