Why is it so damn difficult to get an Ansible PR approved?

Yes, that is exactly the representation of my last experience with Ansible PR.

A long run and a dead-end in the middle of a harsh desert: surviving between git conversations, trying to read someone’s else mind, chasing people, giving up my ideas and trying to find a meaning to a test result and guessing fixes. That has not always been the case though, so let’s go in order and let me tell you the full story.

• Why on Earth would I submit a PR to Ansible?

In the last couple of years I have been asked to develop some projects using Ansible, so I learnt how to write nice (…read “decent” ) and smooth ( the magic of ignore_error:yes ) playbooks . In many cases I needed to run too many shell commands or push too many ios_config lines, so it meant that ad-hoc modules were missing for what I was trying to do. From there, I quickly (…that’s not true) learnt how to write filters as well as new modules. After few months I ended up having a bunch of working modules running for our internal projects. From there, I had the idea to share my work with the rest of Ansible’s community so that other people could benefit from it. I was super excited thinking about my modules and standing among the Ansible folks giants. Also, my fair software developer’s skills would have been improved a lot (…what better experience than some code review with proper kick ass python folks?) and learnt a lot of tons dark secrets about Ansible.

• Let’s read the docs first: how to develop a module.

Yes, I did my homework. I read the docs! Hang-on, I said “read” which is quite different from “understood”. Yes, because I’ve always been convinced that writing documentation is not the same than writing good documentation. The difference? Easy, documentation is understood only by who wrote it, good documentation is understood by everyone. From beginners to seniors. As you write documentation, you can also write good documentation. I am sure you can do it! If not, it means two things only: either you are lazy (I am with you, bro!) or you don’t really want to make your software “accessible”. Do you know how frustrating is reading the same bunch of doc lines over and over again, and not getting an idea of what they are saying? That is not just an Ansible problem though, it is quite common everywhere. So, I learnt in the “hard way”, trying to reverse engineering some modules and giving a sense to what I was doing. Drowning among meaningless ( at least for me ) errors, and guessing what was the best way to debug my crap. After many late night coding hours spent with the constant idea that I was better to change job, I have manged to have a working module! The hardest part was done! Or at least…I wished it was true…

• Submit the PR. git, comments and tests.

If I think about GIT, the first thing that comes in my mind is a mine field or a kind of Utah beach in Saving Private Ryan: a wrong move and you are done. I can easily master git add git commit and git push but working with PRs also involved things like fork (pasta time!) merge and the scariest of all git commands: rebase (…don’t ask me what it does. I manged to run it successfully once and that’s it. The longest 10 minutes of my entire carrier. Never again.) The learning curve became steeper and sometimes, but dangerous. Good. No pain no gain.

The most amazing things of PRs are the comments: some savior Ansible folks usually go line by line through your code and mark all the rubbish you have done, asking to fix it. That is an amazing opportunity to learn python tricks and improve coding style…however…this has not always been the case. I came across tough comments in which I have been asked to re-invent all the code, add features that I could not even think in which case I could use them, and to implement a totally different workflow. Don’ t get me wrong, I am always keen to listen especially from senior people, as well as I always agreed with most of the suggestions received, but in some cases I felt like a typist that has to spend most of his time guessing someone’s else logic and trying to implement someone’s else workflow. This also tended to turn my module in something totally different and far too complex for what I originally needed. Is it not better to have a basic and solid working code, so other people can start to use it, and later add features?

Tests. Good luck. That is all I have to say about it.

Ok, let me spend few words on tests. Just few, because I have really spent too much time of my life trying to figure out how to make tests work in Ansible. Poor documentation (read above), lot of false negative (or false positive…I don’t know!), someone asking for unit tests and forget integration someone else asking for integration and forget about unit. Errors that required a lot of guessing, test results hidden in most remote URLs of CI, green and red flags where green not always means is good and read not always means is bad (is that maybe an exemplification of false positive/negative?). To reverse engineering tests was like trying to decrypt the Da Vinci Code. Days of pain and headache. Saying that though, considering that the only tests I knew was smoke testing, I can say that I learnt a lot of things and I feel myself a better software developer (…kind of) having now a good understanding of tests. But please if you want people to do tests, make them accessible. Ansible’s tests are easy to run but not easy to understand.

• Conclusion. Is it worth it?

Short answer: yes. I believe wherever there is a chance to learn, it is always worth the effort even though sometimes it is unnecessary hard. I am honest, most of the time I feel like making PR difficult to merge is done by purpose. It might seems that merge requests are reserved only the very senior chaps.

With Networking taking a big slice of the Automation world though, I believe rules have to be soften a bit otherwise people will try to write its own crap. In these years I have managed to have merged couple of PRs in ansible-networking ( have a look to ios_ntp and asa_og ), some of them are still in pending, and for some of them I just gave-up and share a pip install package ( git-acp-ansible and pyateos-ansible )

Saying that, I really want to thank all the people in Ansible that spent some of their time and energy with me, improving my skills and coding understanding. And do not worry Ansible folks: I will never give up and most important…I’ ll be back.