I believe at the time I couldn’t find any numbers, so my goal was to produce some data more than write a complete article covering virtualized networking on many different platforms.

I don’t want to configure Outlook to show all emails as text, because some HTML emails can’t be read properly that way. I want a way to convert just the current email to text ready for replying using this quoting method. Anyone

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’!

I’ve written a slightly different angle on this in my article ‘How to build 100 web servers in a day’:

http://www.agilesysadmin.net/imaging-or-configuration-management

which, I hasten to add, is CM-tool-neutral

But having a process in place for sharing the cost of web access, equipment and local know how can be a great blow to ISPs. Given clientele can be found, providing the tools and services people want can be provided at a basic level, and thereafter additional billing for time. Oh thank heaven for OSS.

Thanks for sharing!

The internal work in 0.25 to add a framework for passing objects around, including serialized objects over the wire, generalizes that concept to the point where it’ll be easy to add other interfaces for other resource types, and, in fact, we’ve already got plenty of them (e.g., certs and catalogs are exposed via a REST api).

The Dashboard uses that same API, as does the client. Most of the executables don’t use a network API but rather the internal Ruby API, but the network is certainly there and able to be manipulated. Even better, because the Ruby and Network API go through the same framework, you’re guaranteed that anything that can be done in Ruby can also be done over the network.

I don’t think the structured, resource-like data is any more limited than raw data - if anything, because it’s got built-in semantics you’ve got *more* power, not less. It’s true that I don’t ever want to given an SQL-like interface that just lets anyone do anything, but I don’t think anyone’s proposing that here.

In 0.25, Puppet shipped with a REST api for essentially everything that matters to it — catalogs, files, certificates, and more — and we use it internally everywhere. We didn’t finish a couple of small things, but this API is certainly at the heart of everything we do here.

And, of course, before we had a REST API we had an XMLRPC API, which is no less an api for all that it used less cool tech. But then, that’s one of the downsides of having a project that’s 4.5 years old - we used tech that was best of breed in 2005, rather than 2008. If you want to write a tool that talks to Puppet, you can. If you wanted to write a tool that talked to Puppet in 2005, you could have.

Chef was developed so recently that it was able to take advantage of a huge renaissance in web services; we can’t all be so lucky.

So there’s no library/tool split here, there’s just a philosophical difference about how libraries and services should work. Knife is a great example someone scratching their own itch with Chef, but then, iClassify and Foreman and all of the report processors out there are similar examples with Puppet.

Either way it’s clear neither of us has had our last word on this - the future is clearly APIs and integration all around, and it’ll be interesting to see how each ecosystem develops over time.