April 27, 2022
A couple of years back, I wrote a blogpost on obtaining the previous Job ID in Ansible Tower workflow.
Now, let’s go further and create another module to obtain the output of such a job.
Before moving further, I want to specify that I talk about Ansible Tower since this is the most known name for this software, but I could also be talking about AWX or Ansible Controller since those are the same codebase.
AWX is the open-source upstream project.
Ansible Tower is the former name of the Red Hat product based on AWX.
Ansible Controller is the name of the Red Hat Ansible Automation Platform 2 component based on AWX.
Read More 
November 15, 2020
Ansible Tower allows you to create Workflows, which enable you to create complex workflows by putting together multiple Ansible Playbooks.
Ansible Tower Workflows can have some simple logics, such as run different Ansible Playbooks based on the outcome (success or failure) of a previous Ansible Playbook run.
Sometimes, though, you need to have more information about a previous Ansible Playbook run than just the outcome.
I recently found myself in a situation where I had an Ansible Tower Workflow with two Ansible Playbooks into it, where the first one was performing specific tasks.
The second one needed to get and process the output of the first Ansible Playbook.
Since Ansible Tower provides an API to fetch an Ansible Playbook run output, this part is trivial if you know the Job ID that Ansible Tower assigned to that specific run.
Looking around, I’ve not found much information on how to retrieve the Job ID of a different Job, so I looked at the various APIs and found this solution, which I’m going to share with you today.
I’ve not found much information about getting another Job ID because it is usually a bad practice to do such a thing and that very often you can achieve the same goal in a much cleaner way.
This better option, though, was not present in my case.
Due to many constraints I had in this project, this was the best way I’ve found, even if I’ve tried - at least mentally - many other ways before accepting that this was the only one in my case.
Read More 
July 5, 2010
Two days ago, with an email to the Python Announce mailing list, Benjamin Peterson announced the release of Python 2.7.
This moment is of historical importance for the Python project since 2.7 will be the latest major 2.x release.
From now on, only the Python 3.x branch will have additional development.
To ease this change, Python 2.7 will get full support for five years.
The changes between 2.7 and 3 are easy to apply for the majority of codebases, but I suspect that many projects will not make the deadline.
The main reason for my skepticism is that open-source projects have a horrible track record for those changes.
The main reason this happens is that many libraries, used usually by many other projects, are unmaintained or so lightly maintained that such an effort will be hardly doable.
Also, until the libraries get ported, there is no way the applications or other libraries that depend on them will be ported.
Read More 
(Fabio Alessandro Locati|Fale)'s blog