Configuration (mis)management or why I hate puppet, ansible, salt, etc.

> So that ladies and gentlemen is why I hate anything and everything that uses YAML or some other weird custom DSL to do the obvious.

Sure, because I would trust a random clueless programmer to do system administration or to even know what is necessary there. Your rant is totally justified.

> Everything that seems intuitive and obvious to me is either an anti-pattern or straight-up impossible to do with any of those tools.

The same can be said about functional languages from a perspective of imperative programmer. You just don't understand the paradigm. There's really nothing to brag about here.

> Somehow I’m the only one that ended up with the right set of experiences that taught me to avoid all the things these tools champion.

Yes, somehow you're the only one smart out there. All the other people are just plain stupid.

> [...] but not before a whole bunch of hair is lost trying to figure out why some snippet of YAML is not creating the right unix user (this by the way has happened more than enough times now that I’ve stopped counting).

As previously, there's nothing to brag about. You just don't understand the paradigm.

> The stuff I had built at my first job taught me that my intuitions about software systems in general were mostly correct

Oh boy. Here we go.

> The guy that had built this part was pretty smart .. He probably should have trusted his intuitions a bit more and not bowed to peer pressure

Or maybe he knew enough to understand how Puppet could fit into the overall architecture and strategy at this company that is now the second company you've ever worked for.

> Why the fuck are build/ops folks making decisions about how the application should be deployed and configured?

Because that's what build/ops folks are there to do, and congratulations, you've just discovered dev ops. Not every application is nginx, node.js, and mongodb running on a single VM. Sometimes deployments get complicated.

> How is it that these things are obvious to me but not obvious to others?

Wow.

This person hates on Puppet for "reasons" and decries all configuration management tools as awful pieces of garbage, then says Chef is great while consistently asserting that people are sheep for using configuration management tools, then throws in digs at Ansible and Salt with absolutely no context. It seems like he/she extrapolated one bad example of one Puppet use case into a general flaw with the whole lot. It's like he/she drove a Pinto for a bit, had trouble going around one corner one time, and deduces that all motor vehicles are bad and anyone who drives a car is an idiot.

Yup.

I'm trying to create a build-and-configuration-management system for distributed embedded systems development.

The product will have some physical components with embedded software, and some back-end components running on some sort of server somewhere. Some of the embedded devices may be networked. Some may not.

I want to use Continuous Integration to ensure that the front & back end (and all the various testing tools) play nice together, and Continuous Deployment to reduce the risk of manual missteps.

So ... I'm trying to create the build scripts that build the system components (including cross-compiling the embedded SW), run tests and deploy the various components to UAT / HIL / SIL & simulation environments, orchestrate overnight and over-the-weekend simulation runs & generally provide tools to help manage deployment -- I also want to make the whole thing enforce DO-178B-style process compliance, requirements traceability etc.. etc...

Most of this is done in Python, 'cos I want to be able to reproduce the process on my workstation. Moreover, I want it to be portable (Linux, OSX & Windows), location-agnostic (works in any directory), and free from all but the most essential dependencies.

You can run Puppet in a decentralised way:

    sudo puppet apply --verbose --debug --modulepath=./system system.pp

You can also use BASH/Python whatever with Puppet and still take advantage of Puppet's declarative semantics if that's what you need:

     exec { "install_node":
        require => Package[["build-essential", "openssl", "libssl-dev", "pkg-config"]],
        command => "${settings::modulepath}/main/install_node.sh v0.12.7",
        creates => "/usr/local/bin/node",
        logoutput => true,
        timeout => 1800
    }

On another blog I read a very wise notion, which captured the underpinnings which are "wrong" with tools like ansible/salt/puppet.

You can verify that something is set, but this guarantees nothing about the things you haven't set.

Now, this is fine if you purely use the above tools as provisioning, i.e. run the configuration tools on an immutable image. However, often these configuration tools are run on long running machines. And then we're back to pets vs. cattle. With all the faults and difficulties of Docker - at least it does that right.