I think there’s clearly a philosophical divide about much more than ordering. Before the ‘Puppet vs Chef’ debates there were the ‘Why fork Puppet’ debates. I don’t believe the attitudes and answers have changed significantly since then.

Aside from my personal reasons for using chef a year ago in this article, there was a nice writeup by Adam Jacob entitled 9 things to like about Chef around the same period.

Thus, I’m against a follow-up article about the strengths of Chef over Puppet. I don’t believe we can add anything to that discussion in a positive way at this time, and this is why my response was ‘Configuration Management vs Meatcloud: 5 reasons CM wins‘.

While the dependency model arguments are academically interesting, it underscores that it is ultimately a matter of personal preference for the end user; which is more important, a short list of possibilities that make it easier to understand an entire system up front, or a more complicated system that leaves more options available to you in the long run?

If you read this thread very carefully, you’ll find most of the roots of the choices that made me leave puppet. If you’d like to discuss these in detail, you’re welcome to email me, but that is not an appropriate public discussion for the community.

There’s clearly a philosophical divide between those who think resources should be deterministically ordered where necessary and not otherwise (like Puppet), and those who believe they should always be predictably ordered (like Chef). It’s clear from the article which side I come down on, but I’m starting to think Chef’s design has some interesting features which I’d like to write about. I think a follow-up article is needed called something like ‘10 Great Reasons to Use Chef’!

You mention hard questions, but only bring up dependencies. I have no idea what ‘the hard part of dependencies’ that you claim Chef dodges is, and at least a link to where the project ‘readily admits’ that it dodges this question would be helpful rather than being hearsay.

The way Chef handles dependencies is a matter of philosophy, and centers mostly around a “top down” philosophy. Which is to say, you specify dependencies with order. Puppet is the only other configuration management language I have countable experience with. In that case, excluding a little bit of automatic dependencies like this file resource ought to have the directory it exists in, you generally still specify all of your dependencies by hand with requires. At this point, Puppet tries to make sense of all of these requires, which failed to work for me in frustrating ways. Which is sort of the point of this old post, recently renewed with foolish rivalry.

If you have an issue with Chef’s dependency design, I urge you to write your own thoughts out in a post, and pingback here, and perhaps we can help you address them.

Anyway, I’ve done what I can to build an open development community, and I’ll continue doing so. Hopefully we’ll win you back someday.

I plan to evaluate both products head to head in the next two weeks.

I’m a puppet fan and vocal supporter. The problems I’ve run into are frustrating and time consuming. Sometimes I’ve taken the time to look at fixing the problem: in some cases it was too complicated for my time (depgraphs), sometimes I was doing something stupid, and other times the magic (code) just wasn’t there yet to do what I wanted. I’m a systems administrator first, so my time tends to get allocated with that priority. My commits tend to have alignment with my needs, ease of entry to the community, and my skill.

The way Chef handles dependencies I think is indicative that Adam has a different idea about how to deal with this problem. “… some pieces that are differences in philosophy.” Most of the conversations I’ve had with Adam about these sorts of differences he has said that he looked at the code to try to find a way to fix the problems he encountered but it would be too much a fundamental change. Would you want to remove the dependency graph and move to a top down execution? It’s a change in both philosophy and a significant change to the code.

I think it’s unfair to claim HJK has given little back to puppet because of their lack of commits. I saw myself that much time was put into #1010 specifically, iClassify greatly increases the value of puppet and doesn’t do a whole lot without it, and they converted many a shop over to puppet, increasing its exposure. It’s silly to argue the value of these. I know that everyone I’ve met at HJK would hate to see a world where puppet never existed.

I certainly learned a lot from Puppet. Every day of my job is different now because of it and I believe Chef is a child of puppet. Experience showed that certain features didn’t work the way we expected them to, these were fundamental design differences, and so it was time for a rewrite with the benefit of that experience. That’s sorta how open source works, right? If everything isn’t going the way you feel it should you can fork. And hopefully when the dust settles the user gets a product that works the way they want it to.

As to the rest, it’s pretty clear you’ve decided these problems are too much; the ip address is trivially available in server-side templates, and I’ve already expressed my willingness to work with Adam to solve the dependency issues. Apparently Adam was more interested in replacing than working with me.