Hacker News Reader

Comment by tryauuum | Hacker News Reader

I hate ansible so much it's unreal

It's the small things. Why do I have to write more than one task and register intermediate variables if I want to execute a command and see its output?

View on HN

Executing a task while collecting its output is a different operation than a task to display arbitrary output generated by a command's output. Imagine two shell commands: # foo=$(cat bar) # echo $foo

Yes, it's the little things we need to understand, else we'll be confused by false enumeration. Ansible excells at ensuring one (idempotent) task is indeed just one task. Try the '-v' flag for the verbosity you're looking for from one task, as it's intentionally hidden from the default output.

I don't understand the first part of your comment, why do you compare different commands. My complaint is that ansible runs external command, always internally collects it output, but doesn't display it.

Thank you for the "-v". I've run ansible with various amounts of -v in the past but I didn't notice that it does display stdout_lines with it!

Another part of ansible that I hate is that it encourages bad development practices.

Anyone can write a working playbook and put it in some git repo. If you are not actively fighting against it, you might end up with several git repos, hundreds of playbooks and no way to easy understand what code applies to what servers.

Configuration management solutions that feature agent on managed machines and don't do everything over SSH encourage people to organize their efforts in one repo. Because you cannot manually apply your config to server without pushing it to git.

This I disagree with a lot. Ansible does have a lot of unfinished playbooks out there or half baked ones. But there is solid documentation there which makes it pretty clear how to properly design things. Have a feeling people just don't read it.

For work related use cases, I find it very unlikely you would ever pull in a git repo or playbook from galaxy. Coming from Puppet, Chef I always thought Puppet was in a bad state but then I realized it is 2022 and Ansible has exactly zero roles for LDAP that work, or even resemble a thing that would ever make sense to run in a real installation.

Also, if we're talking about what code would run on which server, I do not see where other configuration management tools would perform better. Have you seen the humongous mess one needs to do in Puppet and Hiera when one wants to build a configuration that is multi-os and multi-arch (like just a simple Debian/Ubuntu plus x86_64/aarch scenario not even Windows)? Or even what it would be like if one also manages firmware blobs there?

If I may be so frank... configuration management is a shit show on every available solution. And I am saying that as someone actively being a part of these ecosystems and contributing.

I know the feeling. We use ansible extensively in our company. While it is probably the best tool at the moment to get the job done, it is not a pleasant tool for larger/complex setups.

Like you said, it's the small things. The thing that annoys me most are probably variable scoping and precedence rules. Scoping is practically non-existent; a variable declared in one role can be freely accessed in another, which can easily lead to clashes when your variable names are too generic.

> it is not a pleasant tool for larger/complex setups.

I'd say it still is. People forget you can code your own modules in whatever language you want and just expose a nice declarative interface through Ansible.

Is there a competing config-management tool that behaves more like you want? I'm just curious because I haven't used the others in anger enough to know how they solve the problem you described

I am a fan of SaltStack. With SaltStack approach, you don't have to write additional yaml to see the output of external command's execution. You see / don't see the output of commands based on logging settings in your client (salt-call).

# EDIT: people pointed out that running ansible with additional -v's will indeed print commands. I don't understand how'd I missed that... I've certainly run ansible with -v a lot.

And my favorite part of SaltStack is that you can use jinja in any place of your states

You can use jinja expressions inline with your Ansible tasks' yaml if you want to as well. As for whether that's a good idea or a mess to read is in the eye of the beholder. Personally I do it only as a last resort, but it has been nice to have occasionally rather than some clunky multiple-task alternative.

It's not the same, you cannot put a jinja condition in an arbitrary place of your ansible yaml, even at the middle of any line

(though it's indeed a questionable approach)

If you need to see the output of commands and tasks in ansible, select a different output callback. Where I want something rudimentary, I use `ANSIBLE_STDOUT_CALLBACK=json` and a tool like github.com/okapia/ansible-json-monitor to parse the json.

Is there any sane reason why in all standard modules the keyword “src” has 3 letters but “dest” has 4 letters instead of “dst”, which is pretty standard everywhere? Drives me crazy every time.

If it drives you crazy, why not make a pr to add an alias for dst? For the copy module this line (and the docs) need to be changed: https://github.com/ansible/ansible/blob/cb448097e4ef581a4749...

Aliases are not backward compatible, it’s not an elegant solution. It should have been properly named from the start.

So run ansible -m command instead.

Reply on news.ycombinator.com