Things that I don’t like about Ansible

This article is about version 2.9. Hopefully 6 will be better. Needless to say I am very unimpressed with Ansible. Now it is version 7.

Learning Ansible has been as fun as stabbing my ballsac with sewing needles. Lots of little things you need to know are left out, everywhere. Don’t assume all modules are idempotent because they are not, even though this is one of the biggest hyped reasons to use Ansible.

#1 Lack of idempotentcy

Making Ansible idempotent is a pain in the ass. Sure they tell you about idempotency, but they don’t tell you which modules you need to do xyz to in order to force them to be idempotent. You are basically left to discover that all on your own one module at a time, one error at a time.

The best thing Ansible folks could do is update the damned docs to include information in each module pertaining to how to make it idempotent. You know tell people if there is something they need to know in order to make the shit work properly. The way it is now, is like there are magical unlabeled switches on a cars dash, you know one of them is an ejection seat, but not which one. NOPE that is a surprise and when you get the right switch your ass just goes flying out the fucking car like a jack in the box.

Here are the hoops I had to jump through to make configuring certbot idempotent. You will be doing this ALL OVER THE PLACE., otherwise if provisioning fails and you fix something then run it again… YOU GET ERRORS DELUXE ALL OVER THE PLACE. Idempotent my ass, that is a lie to sell people on Ansible, hell they got me.

- name: Checking if certbot symlink exists before adding it
  register: cert_links
    path: /usr/bin/certbot

- name: Configuring certbot
  when: cert_links.stat.exists == false
  become: yes
    src: /snap/bin/certbot
    dest: /usr/bin/certbot
    owner: root
    state: link

If you don’t do the above Ansible SHITS THE BED BY CAUSING AN ERROR, something about permission denied or some dumb shit, which has nothing to do with overwriting an existing file FFS.

You will be constantly scratching your head and searching google and trying and failing constantly and screaming W…T…F…

Google often won’t be much help when you have issues with Ansible, but it is always helpful with shell scripting. And there are changes between the old and the new version so much of what you do find will be wrong.

With Ansible you go from devops guy to detective guy.

Go from devops to detective in .9 seconds with Ansible

I feel there is lots of promise and too little deliver. If it has already performed some task previously and you run ansible again you may get another error and then you have to stop and figure out how to fix that. You will follow that course until you finally get it all working.

You often have to revert back to shell scripts to get things done. Some modules like copy lack critical features like only copying if the file doesn’t already exist, you have to run checks first. Copy, replace and several are pain in the ass and you don’t figure it out until you have a failed provision and you have to hunt shit down and go through hell. Why not just give us an option we can set?

I decided recently to shift from using shell scripts to provision to using Ansible, because I fall for hype easily and I thought it might be easier than shell scripts. I decided as a first experiment to try to provision a server for WordPress. It seems simple at first, but you have to do things the ansible way, which isn’t exactly spelled out. To someone used to shell scripting, Ansible doesn’t seem like much of an improvement over shell. It actually kinda feels kind of like back-stepping. The main difference is Shell is often specific to the OS you are installing on the server and Ansible is not.

On the other hand at least with my shell scripts I don’t have to keep changing the syntax every new release, it is more write once and leave it. The same can’t be said about Ansible. Everything is easy peasy at first. Then you get to those odd, edge use cases where you need to install and configure something that doesn’t have a module, and all of the sudden you have to drop back to shell after searching for solutions. Unless you want to learn Python so you can create your own. PYTHON, It is a garbage language. Any language that thinks indentation should have meaning is newb POS, garbage language.

Ansible docs leave you hanging sometimes. A few of the modules are full on wonky tits and you have to screw around a while to get them to work the way you need them to.

Poor little copy her wonky tits are fucked

However I am sure some of this will be fixed/updated soon. Also this was from using version 2.9 not the newest version 6 oops 7 now. Not quite sure how they leaped so far skipping 3, 4 and 5. LOL I don’t know how much has changed and how much I’ll have to rewrite to get things working with version 6… I am pretty sure the main difference in versions is Ansible 2.9 is written in Python 2 and 6 is probably in Python3.

I’ve run into some things that might be bugs, I could report each problem I find but that would take a lot more dicking around and time than writing this article. Also 2.9 is going to die soon so is it even worth it?

I can’t imagine how much time I would waste reporting all of the bugs of all of the software I use for programming, web development, devops etc. etc. I don’t have time to hunt down all the logs and type up all the BS and argue back and fourth with people that can’t reproduce etc. etc. etc.

#2 Python

I hate python with a passion. Ansible is written in Python. Python is the biggest pile of hot, rotten donkey shit anyone ever created. (Satan spawned Python and Yaml to torture programmers)

Python oh what a wonderful language

When using ansible you will constantly be adding Python modules and you must make sure you have the proper version of Python installed and install the proper module. You may get package xxxyzz not found and even more fun,( yes in the end of 2022 still FFS). This becomes a hassle very quickly as Python strongly sucks major rank donkey ass. Breaking changes are the worst thing that they could have done to Python. PERL did that, learn from others mistakes. Many other languages have worked around this issue.


Python at it’s very core is the definition of multiple version backwards incompatibility hell. In almost 18 years of programming I have never encountered a bigger pile of Donkey shit of a programming language. Everything about Python is broken thanks to this idiocy. You can’t follow anything from stackoverflow or blogs etc. everything is a try it and fail and dig and try it and fail and deal with python.

What is even funner is when you have more than one piece of software that uses python and one is version 2 and the other is version 3. Now you need to know if you should use pip or pip3 when issuing commands? You also need to know if package xxxya is available in version 3 etc.

Every-time I encounter software written in python it makes me immediately angry, because I know for a fact from previous encounters… I am in for a world of hurt dealing with that flared up, infected hemorrhoid of a programming language.

That is how much I hate python and its BS incompatibility issues and wrong information all over the internet that just wastes my time. Because that package they suggest on stack, was only available in version 2.7 and no one mentions that is the only version it is available for and now you need package bloodyHemorrhoid-3.5 , which you will only figure out after trying and failing and googling and trying and failing and finally stumbling across the solution to that need for that package.

hide the pain meme
Seriously so much of my fucking time wasted on silly shit

In order to use things written in python you eventually have to become a wizard of googling and time wasting.

i am wizard meme
you become a wizard when trying to use shit written in Python.

Honestly Ansible, Salt certbot and others would be better off rewritten in any language other than Python or Ruby the other POS. These young developers have been lied too and duped by college and google. Hell maybe even brainfuck would be better than python.

When you write a piece of software, remember, people other than you have to use that shit. Python needs to die. Nothing that is open to the public for use should be written in Python. It is a horrible language due to the breaking changes alone, forget the wonky ass syntax from hell. I remember when Java was being pushed by all the colleges. I didn’t mind it, I only hated it’s verbosity, and the fact there were like 100 versions and you had to install the right one or make sure it was installed when you installed software. But it wasn’t too hard and there were not major breaking changes all over. Maybe in a few more years if they don’t make any more breaking changes in versions this won’t be an issue. Shit I can run 10+ year old javascript or php without an issues.

But dealing with Python puts me in a really, really angry mood.

#3 Variables work at random

This one blew my mind and had me cussing up a storm. I think this is something to do with how the yaml is being parsed. You NEVER KNOW where the hell Ansible is going to interpolate a variable or just print that shit.

Imagine my amazement when I tried to store my database users name in a variable then use it, only to find some silly shit like this in my database

{{ admin_user }}

I was wondering why the hell my app wasn’t working and a database connection could not be established. I had to ssh into the damn server, then login to Mysql just to discover this beautiful bug. Hell maybe I should check all the other values I tried passing as variables.

I tried it with single and double quotes… then without quotes, it barfs all over you. Oh but you don’t have to quote the variable names when it is used in the -name line only apparently.

jackie chan WTF meme
You’re making me lose my mind!!!

Yep more of that inconsistency I’m talking about. This wasn’t a one off either, this is quite a problem. I never know when Ansible is going to interpolate a variable or screw it up. This makes me hesitant to use variables. If you never know if they are going to work or not WTF is the point??? I don’t want a directory like /home/{{admin_user}} or a db user with name {{admin_user}} I want that shit interpolated 100% of the time, consistently all the time.

If there is all kinds of rules to when things should be and should not be quoted then all that does is cause confusion and requires people to memorize useless shit that could be avoided with Consistency.

Just look at this inconsistent shit.

- name: Create database user {{ admin_user }} with password and all database privileges and 'WITH GRANT OPTION'
    login_user: root
    login_password: "{{ mysql_root_password }}"
    check_implicit_admin: yes
    name: moses
    password: "{{ admin_pass }}"
    priv: '*.*:ALL,GRANT'
    state: present

Isn’t that beautiful. that line in -name {{ admin_user }} actually prints moses. BUTTTTTTTTTTTTTT when you place that same line of code where the name moses is with quotes, it instead inserts the damn variable name {{admin_user}. If you try it without any quotes you get barfed on by Yaml. I absolutely hate inconsistencies!!!

Ok thanks for the help MFER

Note that login_password works fine and password works fine. Also note that unlike in the user module, those passwords don’t have to be encrypted in any special way. It just can’t handle the name field properly. This is only one example. I feel like Ansible is trolling me.

In Mother Software… ansible Troll you.

#4 Lets watch some fires


Test your ansible playbooks extensively before letting them touch a production server. Fire up a server, ssh into it and make sure it did 100% of exactly what you wanted. Check all file permissions and ownership etc. You will find a few places a surprise for you, I PROMISE. If you don’t check everything manually, you will run into so many errors and problems otherwise. A slip in your yaml can give you some shitty results quickly.

Ansible is Idempotent my hairy, toilet paper shredding, dingleberry covered asshole. Everyone tells you that you are not running lines of code you are using code to describe a desired state. GTFO. I wish that were true, but it is not. With Ansible you are programming with YAML and sprinkling Python in that shit for good measure like pixie fucking dust and hoping for the the desired outcome. That is not describing a fucking state that is building the state with horrid spaghetti code. I can do that with shell.

Here is the issue. In order to get things working the way your mind thinks they should (aka intuitively), you have to gain IN DEPTH KNOWLEDGE of how Ansible works.

Read the docs all you want they won’t help for your edge cases and oddities. You have to trial an error your way through and use google constantly and hope to god someone else had the same problem and they found a solution. Quite a few modules are not idempotent and they don’t tell you that and they happily do the same shit and cause errors. Errors that sometimes don’t make any sense unless you have been working with linux a long time, and even then you get lucky to figure it out by guessing and trying shit.

I think the idea is that it is idempotent and should work the same no matter how many times you run it. Silly me for reading that Ansible is Idempotent and you use it to describe what state you want your server to be in…

I keep reading about how ansible is idempotent… So many things are not idempotent. Which makes using Ansible a shitfest at best and makes you want to rip your hair out. Ansible is NOT BETTER THAN SHELL. I can write idempotent shell scripts pretty easily. If you have any competence as a programmer in shell you can too. If your playbook shitsout halfway while running.. have fun fixing your server. You will be searching the internet about the module you are using trying to figure out how to make it only execute if it was not executed on the last run, which failed. This is true of copy, replace, lineinfile and others. How is this superior to Shell where I can awk, sed, grep etc. before issuing a command which prevents errors?????

Yes I am serious

If one part of a system is not idempotent, the the entire fucking system is not idempotent by definition of idempotent. FFS. If I have a list of 100 tasks and something shits out at task 89. Then I fix that and rerun my playbook. I don’t expect a shit ton of more errors to pop up from the other previous 89 fucking tasks. That is a game of fucking dominoes errors.

The problem is that in order to make things idempotent so that errors don’t occur when you use certain modules, you have to jump through unmentioned invisible hoops; while tilting your head to the left and you must have a very specific, very bright red sparkly led buttplug in just right and it has to be set to strobe. Hoops you have to google to find that is. Once you get past easy things, Ansible is not so easy and starts to make you angry by wasting your fucking time, because it doesn’t provide the simple info you would need, so you are left scouring the internet CUSSING ANSIBLE OUT!!!!

And you don’t know any of it will fail until one thing fails and then it is like domino’s. A big fucking game of Google, try, fix, boom another new error, Google, try, fail, try, fix. And that shit keeps happening until you find all the little fucked up bullshit, that all started with 1 simple failure.

It would be so nice if the information you need to use modules properly WAS ACTUALLY IN THE DAMN DOCS OF THE MODULE. It would be nice if the modules pointed out their quirks and wonky tits and other bullshit.

Then you try to find help on stack and people are telling you to use shit from version 6, but they don’t mention it is for version six or some other older version or vice versa. Great, so how the fuck does one do this in version 2.9? I am not rewriting my entire fucking playbook which took weeks to put together with 90+ fucking tasks just so I can try out version 6, to see if the mother fucker even works half way right.

Ansible is starting to piss me off a bit. The more complex the issue I need to solve the less helpful the docs are and the internet are, that is when I switch to good OLE SHELL SCRIPT.

When I read a complaint about ansible and having to constantly rewrite playbooks to make them work with the newest version, I should have run, run far and away to Salt or puppet or chef or any fucking thing. Now I pay the price in lost time.

In order to jump through ansibles hoops you must first hit a wall, then use google to be able to spot the hoops. If there is a way to make a module idempotent, or execute only once if a failure means re-executing the playbook… PUT THAT SHIT RIGHT IN THE DOCS !!!

Apparently some Ansible modules aim to be idempotent but others are not. I had to google to find this information about ansible line_in_file which was one of the culprits screwing up my plays( along with copy, unarchive and others).

This module took some trial and error to get functioning for all the times I needed it. So I looked to the replace module. If you use this module make sure it actually does the shit you want it too.

Then you get un-helpful useless shit like this comment from replace in the docs

It is up to the user to maintain idempotence by ensuring that the same pattern would never match any replacements made.
Thanks that is as useful as saying “Warning farts stink”

So they tell you that you have to maintain idempotence but they don’t even give you as much as a hint how, not a link, NADA. Because you know… it is in their head SO IT MUST BE IN YOURS. Right? Isn’t that how the human brain works? How do you expect an end user to magically understand how your shit works or WTF you mean with un-helpful hints?

Some modules are idempotent, apparently some are not, which ones are is anyone’s guess, because they are not all marked or labeled in anyway nor do they even warn you many times like line_in_file or copy. And nothing in the docs seems to speak of making sure things are idempotent or execute once from what I can find so far.

Many times you won’t know there are issues with your playbook until you run it externally aka in the cloud or another server. My playbook was running flawlessly locally with vagrant and virtualbox. The problems came when it was time to use certbot, that threw an error( port 80 and 443 not open at the time) which stopped the provisioning. I fixed the issue, but the next time I ran ansible it was a shitfest of errors. It was 3 days or 30 hours of rewriting parts to make it only execute 1 time even if ansible runs twice. I’d get one part fixed and then boom another issue, fix that one and boom another and repeat. Many of the modules are not idempotent, NOT AT ALL, which means you are not describing a state, you are checking it then moving forward, step, by step.

Getting a playbook working is like stepping barefoot, blindfolded into a room of legos

In order to assure all modules you use are idempotent, you will be doing more work than just writing Shell scripts. First you must know which ones suck donkey ass, then you have to google and devise a way to make them not suck donkey ass.

It would be nice to know which modules are idempotent and which ones are not and even a tutorial on how to make everything idempotent. I have not been able to find that information in the docs yet while clicking all around.

details meme
I need more details than that please. LOL

I have since done some research and figured out how to use other modules to do checks before running a task. I’ll have to write an article about that. Here is an article that gives some hints. I’ll probably write it after this one so I can remember how to do it next time. Which is what I should have done for the damn password issue. But this info should be right in the docs to be honest.

#5 More inconsistency

I have also noticed when testing locally with vagrant that it seems to randomly skip tasks in my playbook. For example I run my playbook with vagrant up –provision. It acts like it is going through the entire list of tasks etc in my playbook but… it seems to skip a good amount of them even if nothing fails and doesn’t indicate it skipped it, it just doesn’t do it and you don’t know it if you don’t watch like a hawk. If I rerun the playbook with vagrant provision it repeats about 80% of what it first spat out but includes the tasks it skipped/missed/ignored??? in the first evocation. I HAVE NEVER ONCE EVER NOT EVEN ONCE HAD A SHELL SCRIPT DO THIS TO ME… EVERRRRRRRR

This makes testing locally suck balls. Works one time, not the next, works, then doesn’t. Seems to work locally, go to use it in production and BOOM WTF? How can I therefore trust that ansible will do what it is supposed to do 100% of the time in production, which is what matters the most? This means I have to watch the output like a hawk to see what actually happens, did task x do what it was supposed to? Maybe I am missing something, but I don’t think this is how it should work after reading the docs.

For example, right now my current playbook has 73 tasks. The first time I ran it with vagrant locally via vagrant up –provision, apparently 46 of the tasks were executed. When I re-ran the provision with vagrant provision the other 27 were executed.

I am starting to question whether my trusty Shell scripts are actually better. I have automated entire server installs with Shell. I don’t think it took me as long with shell either. Hell I had a blast using Shell with Hashicorp packer to create instances. I can easily make my shell scripts idempotent or execute only once by testing the state they should change, files they should create, is the software already installed etc. etc. etc. Also with Packer an shell scripts, packer reverses and leaves the server in the original state.

This is executing some tasks but not others is asinine and is as useless as an infected wart on a hemorrhoid.

Maybe it is something to do with vagrant but I doubt it, vagrant only loads a server with an OS then runs the ansible playbook.

#6 Password hashing

So I get to this point where I want to create an admin user to use instead of root to install composer and do other things. Some of those things required elevated permissions via sudo, which means the user needs a password.

With most other modules I have encountered you just pass the password you want as regular text or a variable name stored inside a vault encrypted file. So this should be easy, like all the other modules where I add a password right????

borat not meme
Ansible will NOT create a user with the password you supply.

Not the user module. No, it is that one kid in school that tries too hard to be different. Ok so in the docs it mentions you must hash the password yourself before feeding it to the password argument of the user module. Butttttttt, it must be encrypted in a VERY SPECIAL WAY, which they REFUSE TO SHARE WITH YOU. Ok so they give you a link in the docs in the password section. BUT IT IS BROKEN 404.

So now you must google and dig and try and fail and google and dig and try some more AND WASTE MORE OF YOUR TIME. Until……………… you magically stumble across the secret somewhere on the internet that lets you encrypt a damn password the magical way ansible expects it, but doesn’t tell you how to. Yay research time.

Why not just put the god damned information right there in the page where we can read it when we go to use the module if it is that important and mission critical? FFS!

Good thing I quit drinking

Why not just accept WTF the user puts there and encrypt that shit how the hell ever your program needs it to be? Is there really some good reason this can’t be done? Because this is pure BS. I knew I should have written an article about how I got the password hashed when I did it. Now I have to start all over again, this time I will write a DAMN article.

I’ve just run into lots of little snags and quirks and flatout wonky tit bullshit along the way automating various things with Ansible and it gets frustrating. Especially broken links in the docs to pertinent information. But it makes things easier than shell for the most part due to some of the modules, but some need improvement. I’ve automated server deploys with shell before switching to Ansible. I am just wondering if the alternatives are any worse. Did I choose the wrong software? It wouldn’t surprise me with my luck of choosing wrong shit.

The shit in the docs pisses me off the most though. I mean come on man, don’t leave the user hanging all clueless with broken links taboot.

#7 Wacky ass Yaml syntax

Sometimes it is hard to know what level a given parameter should be indented to. And that leads to odd yaml errors, shit that makes 0 fucking sense. Yaml barfs out the most retarded errors I have ever encountered.

Yaml has retarded error messages

You will definitely be using (maybe not) the ansible yaml linter and need to install a special IDE. I use intellij, actually I pay monthly for it. It sucks at yaml so I can’t use that, so I will have to install and use something else.

sweet meme
Yay more BS to install

I hate yaml with a fucking passion. I see 0, fucking 0, let me spell that ZERO, benefit of yaml over json. I love JSON, I fucking hate yaml. And Ansible is programming with yaml and sprinkling python in it. JSON is actually really easy to read, you can have comments in it too. Hell most IDE’s have great support for JSON, not Yaml though, because yaml is one of those “significant indentation” garbage languages.

We really didn’t need Yaml. The spec is insane, especially compared to the short and sweet spec of JSON. Yaml is not an improvement over anything, actually it’s worse. We liked JSON because xml was verbose and complex. What committee of idiots decided that we should get rid of something simple and replace it with something more complex and harder to use???? The biggest problem with the tech industry is everyone constantly jumps on new trends due to lack of experience.

My biggest beef with Yaml is, if you accidentally get one single little line improperly indented… THEN SHIT HITS THE FAN AND YOU HAVE TO DIG DEEP AND HARD TO FIND THE FUCKED UP SINGLE LINE THAT IS PROBABLY ONLY 1 INDENT WRONG. GTFO. It never tells you the proper line or what is actually wrong which makes it 100 times harder to actually find the shit without running it through a linter, which takes extra time to install, configure and then use. Also IDE’s don’t do so well with it, you always need to find some special plugin or some shit. JSON is easy, it just works.

But idiots had to come along and hype some new shit for the industry to suck on like leaking tits. Yaml sucks. Honestly I am just glad that a large part of the software I use was written by professionals long ago, so I don’t have to dick around with Yaml in their configs. Otherwise I would long have given up on Nginx. I love Nginx config files. They use the old ini format that so much good old software uses. The reason is, indentation doesn’t mean a fucking thing. Which means it is 100,000,000,000 times easier to run scripts that change configs for you in an automated situation. YAML SUCKS MAJOR DONKEY ASS JUST LIKE PYTHON FOR THE EXACT SAME REASON SIGNFICANT INDENTATION. That shit is the spawn of satan and needs to return to hell from whence it came.

#8 The linter

I decided I was going to try the linter to help me find the errors before running the plays. Wow I thought, this will be awesome. Then I get to the official docs and it says this shit…

Ansible lint is also supposed to help users upgrade their code to work with newer versions of Ansible. Due to this reason we recommend using it with the newest version of Ansible, even if the version used in production may be older.

Oh great, so is this telling me that I need to install the latest version which is 6 in order for me to what????? REWRITE ALL OF MY FUCKING TASKS TO WORK WITH VERSION 6 JUST TO LINT MY 2.9 CODE???

It took me weeks to write the current shit in version 2.9 I am not spending a shit ton more time updating all of that just so I can lint a fucking playbook. Why do you not provide linters that are version specific?

draw the line meme

#9 Programming in Yaml sucks ass

Have you ever programmed in Yaml? It sucks major ass. I’d far rather program in Shell. When you provision with Ansible you are programming with Yaml and Yaml is no where near as flexible as Shell. Programming with Yaml is really painful. You will be littering your Yaml with Python when using Ansible too. Yeah stop and think about that for a second. I’d rather write some shell, which I do often with ansible. I write shells for what I can’t do with Ansible like installing php composer, then just use script module to run it.
So far I have been using shell with ansible, it is ok this way I guess, for now.

#10 Idempotency is a LIE

Ansible is not at all idempotent. You are not describing the desired state of a server. You are building shit line by fucking line with shitty fucking ass yaml sprinkled with Python FFS. True idempotency is up to you to perform and good lucking figuring out how for each module. You end up writing more code than if you would just use fucking shell and the checks with ansible are a pain in the balls.

You will eventually run into needing to use the stat module everytime before using anything that moves a file, creates a file or directory. It is a real fucking pain. Why can’t shit like that be built in? If a fucking file exists don’t move the mother fucker again and then decompress it etc. for fuck sakes WTF? If a module is to add a line to a file don’t add that son of a bitch over and over if it already exists!!! I is just constant tiny shit like this you don’t expect blowing the fuck up all over when you need to run your playbook a 2nd or 3rd time. Honestly Shell is better for this shit. How did anyone fool people into thinking we need such tools? Shell is not that hard folks.

Want to make sure a directory doesn’t exist before you create it with a module??????? Sure that could easily be added to the fucking Module, but why do that when we can make a fucking fail factory for the user??????????????? Look at this silly shit. This is how you check if a directory exists before you create it? Also how the fuck is this describing state?

# Determine if a path exists and is a directory.  Note that we need to test
# both that p.stat.isdir actually exists, and also that it's set to true.
- stat:
    path: /path/to/something
  register: p
- debug:
    msg: "Path exists and is a directory"
  when: p.stat.isdir is defined and p.stat.isdir

Ok so in the when: section it is not good enough to just check if isdir is defined. No that mother fucker could be anything apparently, we must also check to see if isdir is actually a fucking directory????? The fail is strong in Ansible. Why can’t the file module, which you also use to create directories (because python developers have never heard of single responsibility principle) check to see if the file/directory already exists before trying to recreate it so that errors don’t happen? WTF is so damn hard about that? Can I just use exists instead? That is what I have been doing. I am guessing the is defined and shit is python.

And this proves my point perfectly if you want to be able to really use Ansible you must know Python. Why the hell learn programming language you don’t use just to use a piece of software to deploy the code you actually do write in other languages? What fucking reality does this shit make sense in? I guess Ansible is mostly for Python people who write shitty, flaky software that tortures us all.

For example if you have a module(copy for example) that moves a file . it doesn’t check to see if the file was previously moved or if it exists already. It just happily moves it and fucks shit up. You won’t really notice unless it is something like a configuration file and code further down makes changes to it or depends on it, but the code that makes the changes does so in a task further up the line. Ansible is a real pain in the ass for any sane person not from Python.

How to copy files only if they do not exist?

I had to google to find this so that when Ansible fails on my production servers I can rerun ansible without it moving files it doesn’t need to move. You would think something this simple would be part of the copy module, but surprise it isn’t FFS.

Python Joke

If Python was a baby its rabbid fanboys would be all like

Python developers think their baby is pretty. THAT BITCH IS UGLY







This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: