Is anybody else confused about Chef ?
Chef absolutely confuses me..
Luke is confused too ..
I’m clearly disappointed that someone who has been a high-profile user of Puppet but has never contributed much in the way of code (Ohloh claims 2 commits) would decide to start a whole new project rather than attempt to contribute to Puppet
Now , if you know me a bit you know that reinventing the wheel, or creating identical projects with no clear reasons is something I dislike .
When looking at Chef's FAQ there isn't really a clear reason listed why they wanted to create a new project.
I could understand if Chef were written in a total different language .. but hmm.. it's written in Ruby again .. I can only think of one other area where there are 2 major competing tools written in the same language and that is OTRS and RT, still wondering how that can happen.
One of the core values of an Open Source project is that you can contribute, adapt , and even fork.. why would you want to start over from scratch ?
So launching a competing open source project in that way therefore doesn't really seem like a smart thing to do,
Maybe one way to explain it is the European vs American style of Open Source Adoption ... , Luke has the more European approach (consultancy, build new features, support, train, evangelize, earn a good living) , where as OpsCode with Jesse Robins in charge might head for a more American style (Productize, Dual License , CashOut ).
So can the Chefs please explain why they didn't contribute to Puppet, or as their FAQ , well it doesn't really Answer any of the Questions
Comments
#1 genoius : ---
I've used puppet for my ec2 management for 30-50 machines too for almost half a year now. Not a real good experience. but ehy....everybody has a different opinion. sorry for my english.
#2 Bryan McLellan : I believe my post about the
I believe my post about the chef announcement has a couple good reasons of why chef is a rewrite.
But why bother to write puppet in the first place when we could have just contributed to cfengine? Fundamental philosophy (and personality?) differences. I think Ezra's comment about merb and rails says the same thing.
Who knows what will be the big configuration management tool in five years, but I guarantee you we'll have learned from chef and puppet like we as a community learned from cfengine and will keep striving towards a solution that works best for us.
#3 Luke Kanies : Cfengine => Puppet !> Chef
As Andrew indicates, there's at least one huge, important difference between my decision to write Puppet and the decision to write Chef: I was the single largest contributor to Cfengine other than its primary author.
I made my living off of cfengine for a year or three and did everything I could to make it better, including writing the most widely published tutorials on it; in the end, my decision to rewrite was based on a development process that was essentially entirely closed to anything other than simple bug fixes. Even then, I would have forked but I didn't think I could have worked with C productively, so I decided to pick a language I thought I'd be more productive in.
That's clearly not what happened here - I never once rejected a patch from anyone involved in the Chef project. It's especially galling that Chef's primary claim to differentiation, its internal Ruby DSL, was tackled by me in Puppet over 2.5 years ago, yet there's no indication that anyone involved in Chef even looked at that file, unlike, say, the RailsMachine guys.
I understand that Puppet is not written in the Rails style of coding, and much of it was written when I wasn't exactly the awesomest of programmers, but hey, why don't we just throw the baby out with the bathwater? Many people have found themselves able to code on and extend Puppet - we've got over 50 contributors, and none of them even had to sign a contract.
#4 Ezra Zygmuntowicz : This is the way open source works when it works well
Chef is to puppet as merb is to rails. Look at how big a win merb has been to rails. Now tell me that opscode is a bad open source citizen,
I *tried* to use puppet for my ey-solo cloud offering but it was not flexible enough to get the job done and when I tried to go into the code to hack it I was fairly appalled. It's like a thousand sysadmin monkeys typing in the night. Chef is a properly done ruby project and its flexibillty pays dividends. Please try the project before you cast aspersions on it.
#5 Luke Kanies : When's the merger?
Hopefully, like merb, we'll see the announcement that Chef is being "merged" into its spiritual parent in the near future, then. :/
And thanks for the coding compliment, always glad to find a fan.
#6 Andrew Shafer : Affirming the Consequent
The relationship of the codebases and the question of citizenship are two separate issues.
How hard did you *try* to use Puppet? Did you talk to Luke about it? Email the list? Feature request? IRC?
I don't doubt Chef adds to the ecosystem, but please spare me the good citizenship and 'I tried' speech.
#7 Tim Dysinger : Try? lol
I've used puppet for my ec2 management for 30-50 machines for almost a year now. At times I swore at it like nobody's business. I had a steep learning code to get to a point where I was any good at it. I already knew ruby but I had to spend the untold hours learning puppet's DSL and setup.
I have since ripped out Puppet and replaced it with Chef. Done and done.
Why?
* The super-verbose before & require linking in puppet's DSL is a PITA, stupid, repetitive and blows.
* Puppet's DSL is so verbose that coming from puppet to chef feels like the difference between XML/JSON or J2EE/Rails or Rails/Merb or CORBA/Rest
* Defines not being extensible is a PITA.
* The choice of static classes or non-extensible defines is limiting as a programmer.
* The way variables scope and are immutable once defined is an absolute PITA. Even the puppet book has to go to special pains to explain this.
* The argument that admins don't want to learn ruby is empty. Facter / plugins _requires_ ruby knowledge. Lots of sysadmins know ruby.
* New developers on my team now don't need to learn a new language to help me with sysadmin with Chef now because we use Ruby already for development.
* Chef/Ohai is just simpler and more elegant.
* There is absolutely no way for Puppet to _really_ switch licenses to BSD in reality.
* There is not really a way for Puppet to radically improve the DSL.
As for the argument that Adam _should_ have worked with puppet. That argument makes about as much sense as saying you should have stuck with CFEngine and should not ever have written puppet. What is this? "Required software socialism"? Where did I sign up for that?
Better/leaner/faster/competing O.S. projects happen every day. Whining about a new framework just makes you look pathetic.
#8 Ezra Zygmuntowicz : I tried hard enough.
Wow you guys are angry eh? Get over it already. I run a lot of infrastructure. And we do still use puppet for some stuff so I am familiar with it enough to know it was not good enough to do what I wanted. Simple as that.
Maybe chef is more targeted at developers and puppet is targeted at sysadmins and thats fine. It looks to me that the future lies more with developers then with sysadmins and I think chef plays to that strong point. Its more of a framework for building your own configuration management system that does exactly what you need and nothing more. Puppet is more kitchen sink and much more complex.
So live and let live I say, puppet is here to stay and chef probably would not be here without it. But chef is a *good* thing for puppet, it means you guys did something right enough to be imitated, just in a way we think is more flexible and extensible for the future.
#9 Andrew Shafer : Not Angry
I'm not angry, not really my style...
Most everything you are saying is sensible, the only thing I questioned is the extent to which you attempted to use Puppet and a philosophical assertion about citizenship.
What's done is done, spilt milk under the bridge as it were.
Chef was born shiny and new with another set of lessons to teach all of us.
The only constant is change.
#10 Luke Kanies : Response to Adam
I'm sorry, those reasons just don't quite suffice.
I've already gone on record as being willing to switch Puppet's license away from the GPL to an Apache-style license; I just said I wasn't willing to do the work without some help or funding.
As to Puppet being found wanting, you seemed to find it sufficient to use it at the heart of HJK for the last few years without providing more than 2 patches over your entire usage.
It would have been great to have HJK helping to develop Puppet, instead of leaving Reductive Labs to fund its development while you worked on a competitor in secret.
#11 Adam Jacob : Why Chef?
Thanks for asking! We updated the FAQ to be more clear:
http://wiki.opscode.com/display/chef/FAQ#FAQ-WhydidyoubuildChefrathertha...
For convenience, I'll quote it here:
Chef was born out of our experience building fully automated production infrastructures with a variety of tools. That experience helped us define clear requirements for tool that went far beyond traditional configuration management. After surveying many different Open Source tools, we found that none met our needs.
Developers need a tool they can safely integrate into their code. Chef and Ohai are licensed under the Apache License Version 2.0 - a liberal, non-copyleft free software license. We maintain Contributor License Agreements, which allows anyone who uses Chef or Ohai to know they are free from any copyright or patent entanglements.