AWX modernization: Moving forward

Project Discussions
, ,
1

Hi folks,

I’d like to give an update on the AWX modernization effort. Before we dive in, let’s briefly recap the goals we defined for refactoring AWX into a pluggable, service-oriented architecture:

  • Improved Flexibility: Easier to implement changes and add new features.
  • Enhanced Maintainability: Simplified codebase with clear service boundaries.
  • Better Code Reuse: More efficient reuse of code across different projects.
  • Active Community Participation: Greater opportunity for community members to contribute and shape the project.

Moving away from the refactoring effort

The nature of the work to refactor the AWX codebase meant that the state of the ansible/awx repository has been fundamentally broken.

As part of the approach to the refactoring work, Red Hat engineering used different branches in ansible/awx to complete various phases of the overall effort. All changes are now merged on the devel branch, which is where all work on the codebase is taking place.

In short, the AWX refactoring effort is nearing completion and there is no longer the need to use multiple branches for development. However there is still work to be done in our efforts to modernize the AWX codebase.

Shifting towards developer experience

In the initial post about streamlining AWX releases, we outlined the intent to foster an innovative and collaborative environment for upstream development within the Ansible ecosystem that ultimately results in higher quality code and a better experience for everyone.

That statement is still true today. It succinctly describes our goal with AWX.

We want to make it much easier to contribute to AWX and create customizable AWX builds as we’ve been saying from the very beginning.

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.

To kick start this phase, Red Hat will start by creating and improving documentation to assist with creating working development environments. We encourage developers, at all experience levels, who use AWX to contribute to this effort. Documentation will be available from the AWX community docsite.

An example of the type of documentation Red Hat commits to providing are development scenarios and API reference material, such as the new OpenAPI schema. As we move forward with the modernization effort and work towards providing better developer onboarding resources, Red Hat plans to make additional announcements on the forum to give the community more visibility as well as to gather feedback.

Myself and others from the community team will also provide more frequent updates to the community with at least one update every three months.

Summary

Red Hat engineering has completed the work to refactor the AWX codebase. As the modernization effort continues, focus is on enabling developers and lowering the barriers to entry for contributing to the AWX codebase.

When we first announced our plans to streamline AWX releases, we made it clear that our goal isn’t to offer an exact replica of our commercial product for free. Instead we want to define the future of AWX with input and direct collaboration from the community.

This is why focus on the developer experience is central to the next phase of the modernization effort. When Red Hat initially open sourced the Tower codebase as AWX, there had been little to no community development or input. Now that we’re done with the refactoring effort, we see this as an opportunity to do things differently.

Call to action

Reply to this forum post to share your thoughts and help shape the future of AWX. Please also join us in our efforts to improve the documentation for setting up development environments and contributing to the AWX project.

Links in this AWX update series

Useful links

21 Likes
Transitioning authentication and authorization (RBAC) to the new AWX architecture
Is there a future for AWX?
2

Thanks a lot for this post, Don! Much appreciated to hear. I’d also like to thank everyone who has been involved in any way to the AWX (refactoring) project.

For now, I don’t have direct input regarding shaping the future of AWX, but once discussions start, I’ll sure try and chip in.

3 Likes
3

Thanks Don for this long awaited sign of (AWX) life.

we’re ready for testing and look forward to contribute to the refactored code

3 Likes
4

This is great news! Thx for the update :blush:

3 Likes
5

It’s good to hear from AWX, although to me this sentence raises a concern. AAP as a downstream commercial product said to be a mix of few components, AWX was part of it.
I guess the concern with that sentence - if the part of AAP that would be AWX is still the same AWX offered as FOSS?
Otherwise, there’s a statement I think the community should be aware of.

5 Likes
6

All the AAP components have an opensource upstream project, for example Private Automation Hub is mostly galaxy_ng + pulp + pulp import plugin (I’m probably missing something).

Note that RH has a long history of making everything OSS, even when it acquires closed source software, though it can take time. AWX took 2years to make OSS after RH bought Ansible, there are many hurdles, legal and otherwise to jump through.

1 Like
7

if the part of AAP that would be AWX is still the same AWX offered as FOSS?

I hope I understand the question correctly. Red Hat uses OSI approved open source licenses. AWX is under Apache 2.0 and that will not change (unless it’s to another open source license).

I think you can find the point of saying “our goal isn’t to offer an exact replica of our commercial product for free” in the sentences that follow, particularly:

When Red Hat initially open sourced the Tower codebase as AWX, there had been little to no community development or input. Now that we’re done with the refactoring effort, we see this as an opportunity to do things differently.

8

Hi @oranod,
Thanks a lot for the update. I’m interested in understanding what has actually changed in the codebase, both in terms of functionality and structure.

Do you have a changelog or something similar?
What has really changed from an architectural and deployment point of view?

Also, could you share more information about the next planned release and the migration path?

Thanks

3 Likes
9

I’d like to chime in on this. While we know AAP is built on upstream open-source projects, the definition of “what actually is AWX” has become blurry.

To be clear, I am not implying that this architectural shift is right or wrong. I understand software evolves.

AWX used to be a self-contained system (https://medium.com/@mohamed547754/say-goodbye-to-microservices-say-hello-to-self-contained-systems-84ab9536036b) however, as parts have been migrated out, it now relies on a constellation of separate Git repositories. This fragmentation has introduced side effects regarding maintenance and visibility.

  1. Maintenance lags in upstream dependencies: A prime example is the ansible-ui repository. It hasn’t seen updates in over a year and relies on Node.js 18, which is End-of-Life. If AWX relies on this, the lack of upstream maintenance is a security and stability concern for the community.

  2. Clarity on Feature Parity: It is becoming difficult to distinguish between “Core AWX” features and AAP-exclusive add-ons.

Specifically:

Self-Service Automation Portal: Is this available in an open-source repository, or is it AAP-exclusive.

Automation Reporting and Calculators: Are these features present in the FOSS code, or are they external services injected only into AAP?

What about the AI stuff?

We need a clearer definition of what constitutes the “Core AWX”

3 Likes