There’s also an official blog post on AAP 2.6 (What’s new in Red Hat Ansible Automation Platform 2.6) which looks a bit like there are new features in the AWX part (and not just in other parts). Since I am not familiar with AWX, I have no idea whether that’s really the case though.
Thanks for getting involved with this concern!
I had another meeting with Red Hat today, and the Ansible SME confirmed that they stopped pushing fixes upstream ever since they rearchitected AAP from AWX’s “monolithic architecture” to a modern, more efficient solution.
Red Hat AAP is deprecating their RPM installer (dropping it as of v2.7 next year), so the only supported installs going forward will be via OpenShift or Podman.
I asked about K8s support, and was told that only some specific customers get support exceptions for these kinds of installs.
@Tyderian This basically means AAP is closed-source and RH have no intention to continue develop upstream first?
This upstream product is no longer part of RH catalog?
from Upcoming Changes to the AWX Project
Before we conclude, we should be clear about what will not happen.
- We are not changing the Ansible project
- We are not adjusting our OSS license structure
This is a clear statement from Redhat and I do not believe they would backtrack on this without a statement. Let’s not think the worst and see what the steering comitee can get answers to.
I moved two posts on the awx.awx collection as part of the Ansible community distribution to a new thread since that is a different discussion. Sorry for the confusion, I moved the two posts from another topic… Too many AWX topics for me it seems ![]()
I’m speculating, but I spent a decent amount of time working on AWX deployability a few years ago and specifically tried to get things settled into a universal Operator that ran well in either K8s or OpenShift.
My goal was to make sure individuals could both develop for and run AWX on a typical workstation.
It didn’t seem that goal was emphasized much in the overall push (at the time) towards OpenShift-centric installs.
I know since that time (as I’ve been much less involved in Ansible community in general, though still participate on the sidelines and advocate for it!), the engineers who had AWX on the plate always seemed to have “AWX” the project as a second priority, since AWX never aligned directly with internal OKRs/revenue goals.
I don’t blame anyone internal for it, it’s just one of the forces that works against pure community-driven projects (like keeping AWX and AAP aligned).
But I have been recommending people use alternate tools like GitLab/GitHub CI, Ascender (which also is tied fatefully to AWX), etc.
It just doesn’t seem like use outside of the paid RedHat ecosystem is a priority like it (thankfully) still is for Ansible proper.
I would absolutely love to be made a fool by the above statement, by AWX seeing some activity. Right now it feels like it’s barely on live support, or there isn’t even an internal resource assigned to the community side of AAP/AWX at all.
您好,您可以指出在哪里吗?我英文比较差,通过Ctrl+F没有找到AWX部分。
Hello, could you please point me to where it is? My English is poor, I couldn’t find the AWX part using Ctrl+F.
AWX is a part of the software sold as Automation Hub, I was referencing to that. I am not 100% sure which parts of AH are AWX, since I don’t use either AWX nor AH.
awx is upstream of ‘Controller’, which part of AAP (Ansible Automation Platform), formerly it was the standalone product called ‘Ansible Tower’.
Automation Hub is the RedHat hosted version of galaxy, with certified collections (collections supported by RH and it’s partners), also part of AAP as well as ‘Private Automation Hub’ or PAH, which is the ‘on premise’ version. The upstream project is mainly galaxy_ng (pulp is a backend as well as a pulp import plugin).
AAP has many parts and even more ‘upstream projects’ .. last I counted it was 29 … now i’m pretty sure it is close to double that.
Hi everyone,
I’d like to give a brief update to this thread in the spirit of my previous reply about improving communication. @gundalow and I have been working on a plan that will address questions around AWX and provide more regular updates.
Like I said in my previous post in this thread, we’ve fallen behind in our communication with the changes to AWX. This hasn’t been an intentional plan. There is just a ton of work going on. AnsibleFest and Red Hat Summit feels like it was last week, but here we are in November.
The modernization effort on AWX has involved many architectural changes that are now coming together on the devel branch. If you’d like to get more involved, feel free to take up the offer to run AWX from devel and help us improve the docs.
You can expect to hear more details soon. Please stay tuned.
Honestly I am kinda disappointed by the responses in that ticket so far. How hard can it be for a developer to write down some instructions from scratch to get a running instance (how are you onboarding new employees to work on the project, do they have to figure it out on their own?). They don’t have to be nice super nice or anything, just a plain list of commands and how your current system setup looks like (so people could reproduce in a container or similar) would go a long way.
Or is AWX currently literally in a state that it cannot be started? Don’t get me wrong, that would also be okay.
Great to hear. Looking forward to see the new archtecture with dispatcherd and dab placed in the bigger awx picture.