Puppet 4 is now production-ready

I want to be able to execute a role (or task within a role), much like calling a function, that will be executed at the point it is called (dependencies are all executed before the role executes.

I may also want to call the "function" multiple times within a role, with different parameters, to, for example, deploy a template several times to different named files. And yes, dependencies can execute roles multiple times, but this is business logic that belongs in the main role file, not in a meta file. And from what I can see, dependencies can only call a role as a whole, not a part (or task) therein.

Basically what I have with "include" does exactly what I want, but it would be nice if it was a bit more explicit that I was calling a role component, something like:

# Role X

- name: deploy conf files

  callrole: common::deployconf

  args: name={{ item.name }} val={{ item.val }}

  with_items:

    - { name: 'conf1', val: 33 }

    - { name: 'conf2', val: 42 }

* Because jinja2 is overall a better templating language.

* YAML (not turing complete) + templating = readable and clear (this is how ansible does it).

* Bash (turing complete) + templating = unreadable and messy.

"I want my configuration code to look as clear and readable as my C++" <-- not a great sales pitch :)

The focus to me seems all wrong. Ansible has a blue million modules, but so many of them are incomplete or downright useless. The cron module can handle cron.d files, but it still tries to manage individual lines in the file and tracks state with comments. It can easily get confused and add multiple entries for the same cron job. Puppet had the same problem. The solution is obvious: just make it barf a pre-made file into /etc/cron.d. But why does no CM actually do this?

Over the last year I have spent a lot of time using Ansible, and I've eventually given up on the cron, sysctl, service and get_url modules and resorted to running commands or copying files. This isn't very clean and it can be brittle, but the alternative of fixing the modules is off the table. The debugging or logging support in most modules is literally non-existent.

There also seems to be a pretty serious scaling issue with the way Ansible processes its inventory, even when using the (absolutely essential) _meta optimization that provides the entire inventory in one command. This is at only a few hundred hosts and tens of thousands of variables.

Contrast this with Puppet: while there are a great many things I hate about it, the dependency system and ability to define your own types inside of the DSL was pretty powerful. Too bad that you eventually had to get down to writing Ruby modules to do certain things. Also too bad that they built it as a client-server system, allow you to export resources between hosts, and took forever to make the execution order deterministic.

The final nail in the coffin for CMs and me is that Ansible (along with Chef, Puppet, Salt) try to do so much but have no concept of absolute state enforcement. The host should always either be in state A or B; the CM system should be able to move in either direction between A and B; and it should never be left in a state inbetween A and B. With Ansible it's quite possible to get permanently locked into a middle state, since it may die before handlers are run (which are then never triggered in subsequent runs).

Building these tools is admittedly harder than it looks, but the fundamental building blocks of a CM system aren't that tough. So many recipes boil down to literally a three step process: install package, copy config file (templating is super nice), start service. Stop trying to play nice with local modifications, the whole point is that I want you to enforce state absolutely -- local modifications are the enemy!

I wish there was a CM that focused on getting this stuff absolutely right and then made it easy to build on top of that.

I'll have to make some changes to my pipeline :)