What to Expect During Major Upgrades for Managed AAP Environments

Updated

Major upgrade events introduce new core features, architectural updates, and platform enhancements to the Ansible Automation Platform (AAP) control plane. While Red Hat Site Reliability Engineering (SRE) manages the deployment, major upgrades require proactive planning from organizations to ensure automation continuity.

Upgrade Schedule & Execution

Maintenance Window Alignment

Major AAP upgrades are executed entirely within the standard, predefined maintenance windows. The upgrade policy, regional days, and times do not change for major releases.

  • Duration: The upgrade is designed to complete within the standard 2-hour allotment.
  • Detailed Schedule: For specific regional maintenance window times and emergency patching schedules, please refer to the AAP Managed Service Maintenance Schedule KBA.

Downtime Expectations

  • Control Plane Availability: Organizations should plan for the possibility of temporary control plane (UI and API) unavailability while the upgrade operations occur.
  • Window vs. Outage: The 2-hour window defines the timeframe for the upgrade process. It is not a statement that the environment will experience an outage for the full 2 hours; Red Hat SRE makes every effort to minimize or eliminate actual downtime.

Planning & Preparation

Because major releases introduce significant platform changes, organizations should use the weeks leading up to the event to audit their environments.

1. Documentation & Deprecation Review

  • Analyze Pre-Release Notes: Review Red Hat’s major version pre-release documentation as soon as it becomes available to identify structural changes.
  • Audit for Deprecations: Identify and address any feature, module, or API deprecations. Ensure that existing playbooks and workflows do not rely on components scheduled for removal in the upcoming version.

2. Infrastructure & Cloud Policy Verification

  • Azure Policy Compliance: For managed application on Azure, audit active Azure Policies. Ensure that restrictive custom policies (such as strict resource tagging or restricted VM sizes) do not block RH SREs from deploying new upgrade infrastructure or modifying existing resources.

3. Execution Environments (EEs) & Automation Mesh

  • Validate Custom EEs: Verify that custom Execution Environments are compatible with the new AAP control plane version.
  • Plan Core Component Updates: While automation mesh execution nodes are designed to maintain backward compatibility during the upgrade window, plan to update node components (such as the receptor) post-upgrade to maintain long-term support and compatibility.

4. Leveraging Multi-Phased Deployments

If an organization maintains multiple managed AAP environments (e.g., Development, Stage, Production), upgrades should be phased across different maintenance windows:

  • Early Testing: Configure non-production environments to ingest the upgrade during the first available maintenance window.
  • Validation: Use the days following the initial non-production upgrade to run smoke tests, validate critical automation workflows, and ensure custom EEs behave as expected before production environments are upgraded in a subsequent window.

Need Assistance?

If an organization experiences prolonged issues following a major upgrade event, or requires clarification on specific pre-release deprecations, a This content is not included.support ticket should be opened via the Customer Portal.

Article Type