Personally, the places where I would assist in infrastructure work were typically either small businesses that didn’t have the budget for AAP, so they needed something free or inexpensive to run jobs (many wind up using GitHub Actions or GitLab CI), or larger businesses that have AAP in some areas, but wanted to have their own managed action-runner system for internal purposes, not tied to an AAP subscription.
For those places, it’s still nice to have a supported standalone automation system with user accounts and some features like job scheduling, logs, etc. — and deploying something from a devel branch or in an undocumented / unsupported manner isn’t that enticing.
At least having ‘versions’ of AWX you could target (e.g. “I’m running 1.2.3, and next month I’ll update to 1.3.0”) would be useful, not to mention having an official installation method.
Right now, just looking at how to install/run AWX, I see:
A warning on ansible/awx about releases being paused, so that’s already a bit off-putting towards running it in a production environment.
The page I end up on still requires me to find the install instructions in the sidebar
The AWX Operator install guide talks a lot about operator versions, and much Kubernetes-isms, and recommends Minikube for local development (fine, but we’re getting pretty far into the weeds now).
And with phrasing focusing on developers and development like:
The next phase of the modernization effort will focus on providing developer resources. Specifically we want to make it really simple and straightforward for developers to spin up environments and start working with the new plugin architecture.
It makes it sound like AWX will not be maintained as a project meant to be run standalone, but only for development of Ansible Tower (as part of AAP)? Maybe I’m just seeing this in a negative light, but it really seems like AWX’s new modern flavor is not meant to be run standalone for someone like me, who might want something beyond Jenkins’ capabilities, more suited towards Ansible automation, but also doesn’t have the budget to subscribe to AAP… (but would someday, if a project’s lifecycle grew to that point, and it was easy to migrate from AWX into a Tower instance in AAP).
Its currently not a good tool - to try it out you go down the route described above.. get to the point of needing to deploy k8s for this one thing and decide to go somewhere else.. which is a shame - it will also restrict the open source input from people who might improve things to a much smaller set…
I REALLY want to get to the point where I can deploy a dev instance, a production not crazy complicated instance (via running random scripts/projects on k8s) and if it expands to a point where it is sensible to go farther then either on k8s or pay redhat.
I’m still trying to work out if I should be spending my time on using another tool to run my ansible but really really don’t want to…
On the plus side - I’m hoping it is less likely to just die in the weeds as there has been SOME discussion within the last 2 years now…
Thanks a lot for writing out your extensive view! It immediately reminds me of my first experience with Ansible AWX when i set it up last year, which wasn’t pleasant. I managed to get it working by using/following the GitHub page of Kurokobo, awx-on-k3s.
The installation of Ansible AWX could be something that needs work first before working out other aspects of the new Ansible AWX environment. To have an official way of installing Ansible AWX that doesn’t require a lot of knowledge, components or 3rd party written guides. Though I can understand this might/probably sound(s) a lot easier than done.
I have looked at a AAP-license, but the costs are far from what I can justify. It’d be nice to keep on using Ansible AWX to build a mature platform, which can justify the costs of moving to AAP over time.
Note that this is just the “official” installation variant. My AWX install (latest release) hums fine along in a simple docker-compose with two containers (awx itself & redis, postgres is external).
Last time I checked it wouldn’t reliably record the output of a playbook executing the setup module and outputting the response. And while I’d pay for the commercial version to get useful features - not having access to the source means I cannot hotfix anything there
Last time I checked it wouldn’t reliably record the output of a playbook executing the setup module and outputting the response
This bug was fixed a long time ago, as far as I remember. This was a problem with long logs, it was fixed by optimizing the writing to the database (x10).
