Conflicts while building AWX-EE custom image for Python Module ‘requests’

An issue arose during the construction of an AWX EE (Enterprise Edition) Docker container, where conflicting requests module versions caused problems. Here we detail a workaround discovered after identifying root causes and solutions to ensure compatibility with Ansible collections used in projects without internal conflicts within the base image itself. 🐳

The Problem: Module Conflict During Container Build

While building an AWX-EE custom Docker container, unforeseen module version clashes emerged due to requests—a Python library essential for our Ansible collections (specifically ‘nutanix.ncp’). These conflicts became evident when attempting operations beyond the build stage using ansible-builder.

ERROR: failed to solve: process "RUN python3 -m pip uninstall azure-core" did not complete successfully with exit code 1, indicating an unresolved dependency issue.

The error messages indicated that specific versions of requests were required by different components (nutanix.ncp requested ~=2.26.0 while other dependencies specified their own range). This discrepancy prompted the need for a resolution strategy as per advice found at pip’s documentation on resolving dependency conflicts:

1. Loosen package versions: Altering version ranges to allow for more flexible resolution by pip could potentially resolve the conflict without removing any desired components (not suitable in this case).
2. Remove conflicting packages entirely from requirements files, thus giving pip a clearer pathway toward resolving dependencies—a direct approach that was not applicable due to our specific use cases and required modules within Ansible collections used for development workflows with AWX-EE images.
3. Clearly define package versions in requirement files explicitly: This course of action requires precise control over each module’s version, which is the targeted resolution method hereafter shared.

210.3 ERROR: ResolutionImpossible due to conflicting requests modules across Ansible collections and dependencies within AWX-EE base image—prompting a solution strategy involving overridden requirements or workarounds for module version specification in build processes using `ansible-builder`. 🛠️

Root Cause: Essential Module Requested by Nutanix.ncp Collection Only

Upon delving deeper into the problem, it was discerned that conflicts were exclusively due to ‘nutanix.ncp’—the sole Ansible collection requiring requests with a specific range not harmonious with other conflicting module versions (~=2.26). This insight directed our troubleshooting efforts toward identifying alternatives without affecting the integrity of projects reliant on this core component for their operational requirements:

| Root Cause | Action Taken to Resolve Conflict                     | Explanation & Outcome       |
|-----------|----------------------------------------------------|-----------------------------|
| 'nutanix.ncp' collection with `requests~=2.26.0` version requirement  | Override in project requirements, not container build file             | Resolved conflicts by maintaining the essential module within Ansible projects without internal AWX image conflict—fostering a harmonious workflow while keeping existing dependencies intact and operational during runtime (i.e., building of Docker containers).

Workaround: Isolating Project-Specific Requirements From Base Image Conflicts

Finally, by removing ‘nutanix.ncp’ from the execution-environment.yml within AWX-EE base image and relying solely on project requirements for its installation during runtime—we successfully avoided internal conflicts when using containerized workflows with Ansible collections:

The workaround resolved conflicting dependencies by separating essential module version specification between the build process (containerization) environment which required specific versions, from where they were installed in actual projects utilizing AWX-EE Docker containers. Henceforthy ensuring smooth operations without internal conflicts—a seamless blend of Ansible collections and Python modules within containerized workflows with `ansible-builder`.