Comment by lost-theory | Hacker News Reader

Comment by lost-theory | Hacker News Reader

This wraps up my feelings about CM tools very well. They all seem to follow this "language agnostic" / "it's not really programming!" model, whether it's chef's ruby DSL or ansible's YAML. I don't understand what's so special about this field that it requires a totally different paradigm.

In chef's case, I would rather write simple classes & functions in plain ruby than use the DSL and write "Lightweight Resource Providers".

In ansible's case, I even did a little experiment to show what it would look like to use & call ansible modules as normal python code:

https://github.com/lost-theory/ansible/blob/module_experimen...

https://groups.google.com/d/topic/ansible-project/Zv3Veo77gP...

I would love to see a CM tool that embraced plain python or plain ruby and not try to go the pseudo-"declarative" route, which ends up being IMO too constraining for not much benefit and needlessly reinventing a bunch of wheels (e.g. looping & conditionals, as the article mentions).

I think the intention is to appeal to traditional sysadmins with limited development experience, who don't know ruby, and more importantly don't want to know ruby.

I haven't worked with Chef so I can't comment, but I work extensively on the puppet-openstack project and my experience is that this aversion to actual languages is part of a pipe dream. The only people who are able to work with the modules in any meaningful way are the ones that understand the Puppet DSL and runtime in its entirety, and it's not much simpler than the Ruby language it's based on.

Honestly I don't know what the solution is: part of the DevOps movement is introducing development practices to the management of systems, but that brings with it an inherent requirement that the operators actually embrace the development practices. A quick example of where this can easily fall down is if you maintain a puppet environment of any complexity, you'll end up keeping both the data inputs and the modules in git repos, but if your sysadmins aren't comfortable with git, the adoption simply won't happen.

> A quick example of where this can easily fall down is if you maintain a puppet environment of any complexity, you'll end up keeping both the data inputs and the modules in git repos, but if your sysadmins aren't comfortable with git, the adoption simply won't happen.

As someone who is traditionally more dev side, but has done a lot of casual system administration, this part of things like chef and puppet drives me nuts. I don't want to version my infrastructure in git and then throw it, with no versioning context, up to a server and have it version it again in its own unique, quirky, and honestly haphazard way.

Chef's DSL is particularly egregious, since if you step out of their slightly bizarre subset your code runs on the machine running knife. Newbies tend to get really confused.

I used chef for years without getting past the really confused stage.

Reply on news.ycombinator.com