eolamey

As a packager, I often wonders if developers should package their software themselves. I'm not sure they should produce more than a decent tarball, with clear INSTALL instructions and licensing information. Setting up a clean package building environment (mock for RPM or pbuilder for DEB) is still a hassle.

For what it's worth, I try to maintain RPM packages for graphite for RHEL (and derivatives) over at http://pakk.96b.it/

I would suggest that anyone interested in Configuration Management would read the article, event if they are pretty sure that their tool of choice is exactly right.

I have used puppet in the past an am now a happy chef user. I find that node attributes, data bags and search queries (from the nodes themselves) are very compelling reasons to use chef.

I agree that installing either chef or puppet on even a somewhat recent distro can be difficult, and this might be one of the reasons that CM is not as widespread as it should (I maintain PRM packages for chef, and it is no so easy...). So I agree with one of the points made by the author. But I have to admit I pretty much discarded his other ideas after reading the article at first, even though I poked around in the documentation.

But then, I thought about the points made and I must say that a CM tool made of small, autonomous, well tested "parts" makes a lot of sense. If you think about it, a CM system's job is to configure UNIX servers (mostly), so why not implement it the UNIX way? It is a bit like the Hubot implementation by Ted Dziuba: back to basics!

You CM tools, wether puppet of chef, must: deliver files to nodes and then execute code to ensure that they are in a proper state (it's a bit more complex than that, but not that much). I'm not sure if it's better to use push of pull for file delivery, but this should be an independent task, that could be implemented either way. Using SSH for security and access control seems like a no brainer. Then comes the compliancy part, where code is executed to ensure that the node is configured the way you want it. Why not have a bunch a small programs, which could be implemented in different programming languages, do it?

Let me give an example. Both puppet and chef work, at the lowest level, with resources. You define them in containers (manifests or recipes) and then make sure they are defined on the nodes. You could have "file", "package, "user" or "template" resources (for example), like:

  # this is pseudo chef code for a fictional redis recipe
  package "redis" do version "1.0" end
  user "redis" do uid 230 end
  template "/etc/redis.conf" do
    user "root"; group "root"
    mode "0644"
    notifies :restart, "service[redis]"
  end

  # in a shell script, distributed by the CM tool
  package redis --version 1.0
  user redis --uid 230
  template /etc/redis.conf --user root --group root --mode 0644 --restart redis

I am convinced you still need attributes, bits of data attached to roles and nodes, for your CM to be efficient, but I don't see any reason this could not be implemented in cdist.

Anyway, this comment is getting really long and I am not sure I made my point. I guess I'm more thinking out loud rather than commenting on the article :)

Do yourself a favor, read the article, put aside the implementation details and website design, and think about the underlying points.

I haven't looked at puppet in a while, but I think this feature is only possible in chef, where each node can execute search queries on the chef server. It is actually one of the reasons I prefer chef to puppet. I guess since the developers of the tools are coming from the puppet world, they did not think about implementing it.

Wether this kind of feature should be implemented in the CM tool is another debate :)