AnsibleByExample

AAP 2.7 PostgreSQL 17 and Django 5.2 LTS: What Changed Under the Hood

Beginner
2024-01-014By Luca Berton

Lesson 1 of 14 in AAP and AWX

Ansible Automation Platform and AWX — full curriculum
  1. 1. Understanding AWX and AAP Architecture
  2. 2. Installing AWX with the AWX Operator
  3. 3. Projects: Connecting Git Repositories
  4. 4. Inventories and Inventory Sources
  5. 5. Credentials and Credential Types
  6. 6. Execution Environments with ansible-builder
  7. 7. Job Templates: Running Playbooks as a Team
  8. 8. Surveys: Parameterized Self-Service Automation
  9. 9. Schedules and Notifications
  10. 10. Workflows: Chaining Automation with Approval Nodes
  11. 11. RBAC: Organizations, Teams and Roles
  12. 12. Automating the Platform: API, awx CLI and ansible.controller Collection
  13. 13. Troubleshooting Jobs and Platform Operations
  14. 14. Capstone: Production Workflow with Approval and Rollback
View path overview →

Red Hat Ansible Automation Platform 2.7 lands with a quiet but consequential foundation refresh: PostgreSQL 16 and 17 support, a Django 5.2 LTS upgrade, and a gateway-only architecture where every inter-component call is routed through the platform gateway. None of this changes a single playbook you write, but it changes what you should check before an upgrade.

Verify database and dependency readiness before upgrading

---
- name: Pre-flight check before AAP 2.7 upgrade
  hosts: aap_database
  gather_facts: false
  vars:
    supported_pg_versions:
      - "16"
      - "17"

  tasks:
    - name: Query running PostgreSQL major version
      community.postgresql.postgresql_info:
        login_host: "{{ aap_db_host }}"
        login_user: "{{ aap_db_user }}"
        login_password: "{{ aap_db_password }}"
        filter: version
      register: pg_facts

    - name: Fail fast if PostgreSQL version is unsupported by AAP 2.7
      ansible.builtin.assert:
        that:
          - pg_facts.version.major_version | string in supported_pg_versions
        fail_msg: >
          PostgreSQL {{ pg_facts.version.major_version }} is not supported by
          AAP 2.7. Upgrade to PostgreSQL 16 or 17 before proceeding.
        success_msg: "PostgreSQL {{ pg_facts.version.major_version }} is supported."

    - name: Confirm gateway service is the sole ingress for platform traffic
      ansible.builtin.uri:
        url: "https://{{ aap_gateway_host }}/api/gateway/v1/ping/"
        method: GET
        validate_certs: true
        status_code: 200
      register: gateway_ping

    - name: Report gateway reachability
      ansible.builtin.debug:
        msg: "Gateway reachable, version {{ gateway_ping.json.version | default('unknown') }}"

What this does and why it matters

The play does two things a migration runbook should always do first: confirm the database engine is on a version the new platform release actually supports, and confirm the gateway is the single reachable entry point for the stack.

  • PostgreSQL 16/17: AAP 2.7 adds support for PostgreSQL 16 and 17 alongside continued support for earlier supported versions, so this is the moment to plan a database engine upgrade if you're still on an older release. Checking major_version against an explicit allow-list before you touch the platform install avoids a failed migration mid-upgrade.
  • Django 5.2 LTS: the controller's API layer now runs on Django 5.2 LTS. This is an internal dependency bump — no controller/EDA/gateway API contract change is implied by itself — but it means the underlying async ORM, security patch cadence, and Python version compatibility window all shift to match Django's own LTS support timeline. Custom scripts that shell out to manage.py or import controller internals directly (not the REST API) are the ones that can break.
  • Gateway-only architecture: in 2.7, all inter-component traffic (controller, hub, EDA, gateway) goes exclusively through the gateway — no more direct service-to-service calls — and this is enforced and regression-tested by Red Hat. The uri ping task above is a stand-in for the kind of network-policy validation you'll want if you run AAP behind segmented firewalls: any previously-opened direct port between, say, the controller and hub is no longer part of the supported traffic path.

Notes / Gotchas

  • Don't skip the PostgreSQL major-version check on managed/EUS installs — mixing an unsupported engine version with a platform upgrade is a common source of failed migrations.
  • If your firewall rules were built around AAP's older peer-to-peer service topology, audit them now: gateway-only routing means those direct rules are dead weight at best, and a false sense of security at worst if you were relying on them for segmentation.
  • A centralized OpenAPI spec also ships in 2.7 — if you generate API clients from spec files, regenerate them against the new centralized document rather than per-component specs you may have cached.
  • AAP 2.4 reaches end of life in June 2026, so this foundation refresh is arriving right as 2.4 deployments need a decision: upgrade or move to Extended Update Support.

Takeaway: AAP 2.7's PostgreSQL 16/17 support, Django 5.2 LTS, and gateway-only architecture are foundation-layer changes — validate your database version and network paths before upgrading, and the rest of your automation content keeps working unchanged.

References

All Tutorials