types.markdown

My basic point is that currently, configuration management code manifests as a giant, unverifiable pile of mud. The languages we use lack types and are weak at making non-runtime assertions. With the modicum of sanity that a proper module system and types can bring to the table, we would be considerably better off.

The fatal flaw here is the assumption your verifiable, strongly-typed configuration language is anything more than a map for the unverifiable pile of mud territory that is the underlying system you are trying to manage. The map is not the territory. The issue is not weaknesses in the languages used to express configuration management systems, although they almost universally fail there. It is that the underlying systems are often antagonistic to attempts to wrap consistent abstractions around them.

One example of this that springs to mind is that it is unlikely the configuration management system will know what all of the files and actions that a "package install" will be, and thus what the state of the system is after that has completed.

@b In reference to me believing in:

"more than a map for the unverifiable pile of mud territory"

I'm hardly that religious. I understand what we're dealing with "underneath," but I truly believe that this is a strong first step that we can take - someone with more brain power than I could certainly figure out how to statically verify AT LEAST SOME aspects of what now is a hopeless, terrifyingly long feedback loop. Pushing the results of our Ruby cookbooks into the giant blob of JSON in the sky is not the best we can do.

The entire model is broken. The rapid adoption of half-baked technologies like Docker shows how desperate people are for a better model that avoids this trouble in the first place. Sharing components between disparate processes on a system is a constant source of pain, and no amount of package management intelligence can fix that. Mutating systems in place is a good way to take things from one partially understood state to another, with no way back. Like security, you can't bolt configuration management on the side.

Rule #1: The best solution to a problem is not to have it.

Bake the notion of constructing immutable deployment artifacts into the system. Bake the notion of multiple systems in an ensemble into the system. Bake the notion of ensemble lifecycles, via state machines and events, into the system because these things need to be immutable but they sure aren't static. But whatever you do, don't waste time polishing the mutable, bolted on configuration management turd.

Super agree with @b in terms of don't waste time polishing the mutable, bolted on configuration management turd

But was thinking that docker could be one of the mechanisms (along with a stripped down minimal os like CoreOS) to get there Its not inherently immutable, but it could be used in an immutable way from what I can tell.

It seems that Docker is evolving to a component architecture where containers become like black boxes of functional goodness. It has Links (defined input/outputs) and attributes set via /etc/etcd and otherwise treat it as a black box with an API.

In the short therm the Containers / Lego components are made with "old school" service implementations like Nginx, tomcat, mysql, whatever. But they get constrained by explicit container APIs and not but a mud of config files, packages, etc.

The Docker linking model is strictly local and extremely primitive (that is primitive in the stone axe sense, not primitive in the you can build on it sense). This is not surprising as their networking story is nonexistent. Yes, it's a container (3 layers of container, actually), but that is the easiest part of this problem. Probably why it gets solved over and over, while the hard parts of networking and orchestration are consistently broken. Solaris Crossbow, which arrived 5 years after Zones is a good start on the problem and an indicator of just how difficult it is to do the networking properly. Some sort of conception mashup between Erlang supervision trees and Crossbow is a what I keep imagining.