Has anyone seen any news on the AWX Development process? I know it’s in a rebuild / redesign process but it has been two years without any news.
Are there any alternatives to AWX that work well for ansible automation as I may need to investigate something else as the containers are getting very outdated and may not comply with our internal security audits for much longer. (operator / task / web pods not the ee as i can build an ee).
I was just curious if there was any news or if the current recommendation would be to search for another solution to scheduling ansible automation.
I have given up holding my breath for anything AWX related, and I have sadly also given up on believing in or trusting that “there will be updates soon”.
While only AWX will give you everything AWX gave you, I hear quite good things from people using Semaphore UI, Jenkins (with Ansible plugins), and Rundeck (with Ansible plugins).
I get the impression that Red Hat’s main focus is more on enhancing AAP (the downstream product) than AWX itself.
Although there are still active commits happening in the ansible/awx and ansible/awx-operator repository, it feels like many of them are side effects from work done to improve AAP.
So even if the ongoing refactoring is completed, it may not necessarily mean that AWX, the AWX Operator, or various plugins will be released with versioned tags in a way that’s particularly easy for community users to adopt, such as with detailed documentation or streamlined deployment guides.
It seems the priority for creating assets mainly for the community isn’t especially high right now.
It looks like Red Hat’s motivation for investing in community support is gradually becoming less prominent compared to the value they get from the community’s feedback and contributions.
Of course, it’s understandable for a company to focus on business goals, and this approach probably makes sense from that perspective. After all, having more free users doesn’t always translate directly into business benefits.
I might be being overly pessimistic, but I hope the updates from the AWX Team will prove me wrong.
We are currently running our AWX-dev instance with Ascender images as a proof of concept. Generally it feels like how you describe it (less critical vulnerabilities due to more recent dependencies).
One of the differences I noticed (besides the slightly modified UI theme):
Ascender did not apply the changes on RBAC introduced via the more recent AWX releases. In a way this makes sense, since it diverged from an earlier AWX release and even in the currently most recent AWX release (24.6.1) the RBAC improvements are not finalized (as in: there are still some quirks here and there (#14657), the new RBAC API endpoints coexist next to the deprecated ones; I believe, both are still used by parts of the application)
This is not bound to be a deal breaker, since for migration to Ascender you have to export your AWX resources and import them on the other side anyways (due to DB scheme changes, probably introduced e.g. by more recent django versions etc.).
But I´m not certain about that. We have not made use of the most recet RBAC features (creation of fancy specialized roles etc.), yet, so my guess is, it would be no problem for us to migrate.
Migrating back would be export/import again, which we would develop a migration pipeline including reencryption of secrets (which by design are not exposed by AWX API and therefore not exported)
We are considering the switch, because it´s rather manageable (to switch back as well) and it gives us time to think about different solutions, while being able to keep running AWX with less vulnerabilities.
It goes without mentioning that of course this is less ideal than a working path to the most recent AWX versions used as AAP´s core.
Hi Klaas , thanks a lot for sharing . So actual we are using the awx.awx collection for controller automation . Not everything is possible but 80% are enouph for us.
Can this run on standard k8s or is it just for k3s and the cloud systems listed in their install instructions. Has anyone installed it on just k8s before?
Is there a cost to this or is the community edition available to those that do not have a budget for these systems.
If you set the installer to k3s, but ensure kube_install is set to false, it should deploy on standard k8s, as its just creating and applying basic manifests at that point. Its a fork of Open Source AWX, there is no cost unless you want commercial support.
