Hacker News Reader

Comment by Havoc | Hacker News Reader

Author should have stuck with ansible a bit longer.

It can stream shell commands so you've got all the usual sed awk etc

And has a battle tested OS detection logic built in.

>This value is correct for Debian and derivatives, but not for my Gentoo or FreeBSD systems, so I’ve created OS-specific configuration files for these.

And can copy in different templates depending on OS.

Hell it can even detect whether its in a KVM or LXC or metal environment with right helpers and same for architecture so very useful for building a script that works in a very mixed environment

Still to each their own. I occasionally feel the need to reinvent a specific wheel too.

View on HN

I've tried Ansible multiple times. Every time it seemed to cost more effort to do something simple, and once you start mixing OSs, things get much more complicated very quickly.

> It can stream shell commands so you've got all the usual sed awk etc

I can write a couple lines of yaml which includes the line of sed/awk/whatever, or just write the one line of sed/awk/whatever.

> And has a battle tested OS detection logic built in.

You can get pretty far with just checking /etc/os-release, and you'll need only a fraction of the code Ansible brings to do that. Ansible might do a _slightly_ better job, but the increased complexity is definitely not worth it.

> And can copy in different templates depending on OS.

Yes, it can do this, and I have done this. It's a lot of boilerplate YAML you'll need _every_ time you want to write any playbook. It's just not worth the ridiculous amount of hoop-jumping for something which seems to me to be a rather straightforward use case.

I didn't look too closely at this but Ansible offers a number of guarantees such as idempotency, locking, etc. If this thing is just people wrapping their shell scripts in on of the functions this thing executes then it's automatically worse than just using Ansible. Because nobody is going to care to make their script...good.

my experience with ansible is that it offers a suggestion of idempotency, but there's always plenty of room to ignore the best practices.

IMHO it's better to have no guarantee than a vague suggestion that you might tend to rely on but then be bitten because there's nothing actually enforcing the guarantee.

I'm pretty sure that all of Ansible's core builtins guarantee idempotency

The core builtins help you to write idempotent playbooks, but it is far from a guarantee.

One simple example would just be to use the command task, which executes an arbitrary command. You, the developer, are responsible for telling Ansible how that should be made idempotent.

Right but no configuration system can do this. Puppet straight up tends to lie about what it can do with operations named things like "ensure" which play with language to make it feel like there's not actually a procedural, stateful system there (at least based on the number of people who have gushed at me about puppet while not using it).

It's akin to "unsafe" in Rust and ansible does warn you it's a bad idea unless you really need it.

>Ansible offers a number of guarantees such as idempotency,

You can wrap anything in ansible basically, including stuff that isn't idempotent.

Some of their modules are definitely conducive towards achieving it though.

Reply on news.ycombinator.com