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.

The argument for passing raw data instead of resources is that you limit what one can do with the data to what you expect and allow them to, in the latter. When I spoke of the API limitations I was specifically speaking of the external node interface, and how it made it difficult to access data about nodes in modules, compile that data and use it to build content in configurations.

I think your reasoning makes for an interface that is easier for people with less development experience to pick up and manipulate on their own, but eventually that design has always eventually formed roadblocks that frustrated me personally.

Ultimately this post was the tools that users have developed, extending by scratching their own itch. James Turnbull commented on twitter as well that this is an early release of the dashboard and there is much more to come, even going so far as to file an issue for the feature I always wanted.

Perhaps this will always be a defining difference between configuration management tools and libraries. Which is great of course, as the diversity will bring more users into the fold realizing the absurdity of configuration by ssh-for-loop. With more users I believe we will benefit with more innovation from the additional mindshare.

Thanks for the interesting pointer on this development in the Chef world.

It’s worth noting, to start, that our dashboard is following a “minimum viable product” model – we’re releasing as soon as we have something that’s functional enough to be useful, so don’t assume that missing functionality will always be missing.

There are multiple reasons why Puppet didn’t adopt the iClassify way of thinking about the world, but none of them relate to missing APIs. Puppet has tons of extension points, and we’re adding more all the time. We don’t do the best job of documenting and advertising them, but it’s not like they’re hidden, either – I meet people every month who are doing interesting things with them.

That being said, we are adding new ways of exchanging rich data. I never liked the way iClassify builds APIs on raw data, expecting the consumers of that data to add all of the necessary bits. I much prefer exchanging richer data – transfer resources instead of simple hashes, for instance.

Anyway, don’t worry; we’ll start copying the Opscode guys, too – information exchange won’t all be from us to them.