Hi folks,
Welcome to the next post in our ongoing discussion around changes to modernize AWX. In the previous post, we talked about removing the AWX Operator from OperatorHub.io and relocating the Helm chart for the AWX Operator to a repository in the Ansible community org on GitHub.
As the next step, we are sharing more details on the pluggable, service-oriented architecture for AWX. Before we dig into the details, let’s recap some of the expected outcomes from the initial post announcing the re-architecture of AWX into pluggable services:
- Improved Flexibility: Easier to implement changes and add new features.
- Enhanced Maintainability: Simplified codebase with clear service boundaries.
- Efficient Code Reuse: More efficient reuse of code across different projects.
- Increased Community Participation: Greater opportunity for community members to contribute and shape the project.
Upcoming changes
The first step is making changes to convert the following components to the new plugin architecture:
- User interface (UI): The new Ansible UI framework will replace existing project UI, including the AWX UI. The existing AWX UI will be removed from the AWX repository.
- Inventory sources & credentials: Inventory source plugins and credentials plugins will move to a new repository.
AWX UI
At the AWX community meeting in November 2023, the AWX engineering team at Red Hat gave an overview of the new UI framework and a demo of running AWX with it. And the past several AWX releases have featured two UIs, with the new one being opt-in. This new UI creates a unified, consistent experience in each of the upstream projects and across the Ansible Automation Platform.
These changes will result in a simplified, more stable, and more efficient UI. Additionally, with the change from AngularJS to Patternfly, more enhancements will be available such as enhanced accessibility features and a more modern interface. You can access this UI in the new ansible/ansible-ui repository.
Inventory and credentials plugins
Most inventory source plugins and credentials plugins that are currently in AWX will move to a new plugins GitHub repository. This move will not only make the codebase in ansible/awx much smaller, it will also make it easier to contribute to and test these plugins.
For instance, if you wanted to test the Foreman / Satellite credentials plugin, you would currently need to spin up an entire AWX instance. Or if you wanted to create a new credentials plugin, you’d need to take backwards compatibility with the API into consideration in some cases. Decoupling plugins from the rest of the AWX codebase removes these constraints and makes it a lot easier to do things like create and test plugins.
While some AWX plugins will remain, the following will be relocated to the new repositories.
Inventory source plugins:
- azure_rm
- ec2
- gce
- insights
- openshift_virtualization
- openstack
- rhv
- satellite6
- terraform
- vmware
Credential plugins:
- aws
- azure_rm
- bitbucket_dc_token
- gce
- github_token
- gitlab_token
- gpb_public_key
- insights
- net
- openstack
- rhv
- sattelite6
- terraform
- vmware
Customizable AWX build
As we mentioned in the previous post, Red Hat engineering teams will streamline efforts around workflows by minimizing existing duplications, particularly related to releases, and avoiding future duplications.
When we moved from Ansible’s batteries-included model of modules to Collections, it allowed more granular plugin specific GitHub repositories to be created, each with a dedicated purpose. These dedicated repos were much easier to maintain. As they were only for one application (MySQL, Zabbix, etc), the dedicated repos allowed for much more in depth testing and the ability to release independently.
We plan to build on the success of that model as we move AWX code into more narrow and dedicated purpose repositories. This also allows for cleaner separation between upstream code and plugins that are Red Hat-supported or partner-supported.
Summary
We are committed to communicating the changes we are making in these posts, so stay tuned for more updates. We’re hoping these changes lead to an increase in community collaboration and innovation, and will improve the horizons for AWX and sustain it as a project for years to come. For example, in a previous post, one comment mentioned having custom installable plugins for AWX, which is a very interesting idea we’ve noted and believe warrants further investigation.
We do not want our technical debt to be a blocker to contribution. By giving more flexibility to AWX users, we are enabling:
- builds that meet specifics based on the user needs
- customizations to those builds based on deployments and use cases; and enhancements to those builds via community contributions.
