AnsibleByExample

Ansible Intelligent Assistant Example: Configure Azure OpenAI as the Backend

Beginner
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

The Intelligent Assistant is the chatbot embedded in the AAP UI, and starting with AAP 2.6 it supports Bring Your Own Model (BYOM) backends beyond Red Hat AI — including Azure OpenAI. This example shows how to point the Intelligent Assistant at an Azure OpenAI deployment using an Ansible playbook against the AAP Gateway API.

Example playbook

---
- name: Configure Intelligent Assistant to use Azure OpenAI
  hosts: localhost
  gather_facts: false
  vars:
    aap_gateway_hostname: "https://aap.example.com"
    aap_gateway_username: "admin"
    aap_gateway_password: "{{ lookup('env', 'AAP_ADMIN_PASSWORD') }}"
    azure_openai_endpoint: "https://my-org-openai.openai.azure.com"
    azure_openai_deployment: "gpt-4o-mini"
    azure_openai_api_version: "2024-10-21"
    azure_openai_api_key: "{{ lookup('env', 'AZURE_OPENAI_API_KEY') }}"

  tasks:
    - name: Create Azure OpenAI credential for the Intelligent Assistant
      ansible.controller.credential:
        name: "Azure OpenAI - Intelligent Assistant"
        organization: "Default"
        credential_type: "Azure OpenAI"
        inputs:
          endpoint: "{{ azure_openai_endpoint }}"
          api_key: "{{ azure_openai_api_key }}"
          api_version: "{{ azure_openai_api_version }}"
        controller_host: "{{ aap_gateway_hostname }}"
        controller_username: "{{ aap_gateway_username }}"
        controller_password: "{{ aap_gateway_password }}"
        validate_certs: true

    - name: Register Azure OpenAI as the Intelligent Assistant model backend
      ansible.controller.settings:
        settings:
          ANSIBLE_AI_MODEL_PROVIDER: "azure_openai"
          ANSIBLE_AI_MODEL_NAME: "{{ azure_openai_deployment }}"
          ANSIBLE_AI_MODEL_CREDENTIAL: "Azure OpenAI - Intelligent Assistant"
        controller_host: "{{ aap_gateway_hostname }}"
        controller_username: "{{ aap_gateway_username }}"
        controller_password: "{{ aap_gateway_password }}"
        validate_certs: true

What it does

The first task creates a dedicated credential in AAP holding the Azure OpenAI endpoint URL, API key, and API version — kept separate from other credentials so access can be audited and rotated independently. The second task updates the platform-wide settings that tell the Intelligent Assistant which provider, deployment name, and credential to use when answering chatbot queries in the AAP UI. Once applied, every Intelligent Assistant conversation in that AAP instance routes its completions through your Azure OpenAI deployment instead of (or in addition to) Red Hat AI.

This is BYOM in practice: AAP 2.7's provider compatibility matrix, presented at Red Hat Tech Day Netherlands 2026, confirms Azure OpenAI as a supported Intelligent Assistant backend from AAP 2.6 onward, alongside Red Hat AI and OpenAI. Note this differs from the Coding Assistant (the Ansible VS Code extension), where Azure OpenAI support is still listed as "Coming Soon" — the two AI surfaces have independent rollout timelines even though they share the BYOM concept.

Notes / Gotchas

  • Module and field names are illustrative. ansible.controller.settings and the exact ANSIBLE_AI_MODEL_* keys shown here follow the shape of existing AAP settings modules; confirm the precise setting keys and credential type name against your AAP 2.7 Gateway API docs before running this in production, since BYOM configuration surfaces were newly introduced and may differ slightly by patch release.
  • Store the API key as a secret, never inline in the playbook — use lookup('env', ...), an Ansible Vault-encrypted variable, or an external secrets manager.
  • Deployment name vs. model name: Azure OpenAI addresses models by the deployment name you configured in Azure, not the underlying model family name (e.g., gpt-4o-mini the deployment, which might actually back a different model version). Double-check this matches your Azure resource exactly.
  • API version drift: Azure OpenAI's REST API version (api-version query parameter) changes periodically. Pin a known-good version and revisit it during upgrades.
  • IBM watsonx is not supported as an Intelligent Assistant backend at all — don't confuse it with the Coding Assistant matrix, where watsonx was the first external provider supported (AAP 2.5+).
  • If you also plan to use BYOK (Bring Your Own Knowledge, Tech Preview) to ground answers in internal runbooks or compliance procedures (PCI-DSS, HIPAA, SOC2), that RAG pipeline configuration is separate from the model backend setup shown here — BYOM picks the brain, BYOK picks what it's allowed to read.

Takeaway

Wiring the Intelligent Assistant to Azure OpenAI is a two-step BYOM operation — a scoped credential plus a settings update — that lets AAP 2.7 organizations keep their existing Azure OpenAI investment instead of relying solely on Red Hat AI.

References

All Tutorials