feat: Ansible Automation Platform Updates for 2.5/2.6

[BBGrimmett2]

Automation Controller

• Updated path from instance to controller-instance

ansible-automation-platform/controller-instance/README.md

• Removed reference to ConsoleLink with Gateway being the Unified UI for AAP
• Updated references in commands to new path controller-instance

ansible-automation-platform/controller-instance/base/automationcontroller.yaml

• Removed ArgoCD annotation

ansible-automation-platform/controller-instance/base/kustomization.yaml

• Removed reference to console-link

Automation EDA

• Created EDA deployment matching direcotry pattern for controller-instance and hub-instance

ansible-automation-platform/eda-instance/base/automationeda.yaml

• Created deployment file with base CR

Automation Hub

ansible-automation-platform/hub-instance/README.md

• Removed reference to ConsoleLink with Gateway being the Unified UI for AAP

ansible-automation-platform/hub-instance/base/kustomization.yaml

• Removed reference to console-link

Automation Platform

ansible-automation-platform/platform-instance/README.md

• Added reference to custom CRs in AAP documentation to show how to hook in existing components

ansible-automation-platform/platform-instance/base/automationplatform.yaml

• Created deployment file with base CR using managed components

ansible-automation-platform/platform-instance/base/console-link.yaml

• Moved ConsoleLink to Automation Platform resource
• Cleaned names and sections in deployment

Operator

• Did NOT remove 2.1, 2.2, and 2.3 examples so they can still be referenced in overlays

ansible-automation-platform/operator/README.md

• Removed README references to AAP 2.1 to 2.3 as does not match current supported deployments (see AAP Lifecycle)

[strangiato]

What is the goal of renaming from instance to controller-instance?

Instance is a common pattern we use throughout the catalog so i am hesitant to deviate from the current pattern without a reason.

[BBGrimmett2]

My thought behind this was the AnsibleAutomationPlatform custom resource is now the full deployment with AAP 2.5+. Changing the name to controller-instance matches the "plumping in" that we document in adding existing/separate controller instances into the AnsibleAutomationPlatform CR (see here)

Open to changing the names to match the pattern; however I would then change platform-instance to just instance to match the default CR (here)

[strangiato]

Yes, I think that instance would be my preference.

Inside of instance I would recommend something like this:

instance
├── base
├── component
│   ├── feature-1
│   └── feature-2
└── overlays
    ├── deploy-method-1
    └── deploy-method-2

Based off of what you have described you could have the separate examples for each deployment method in the overlays folder. If you have "common" features for those different examples you may consider adding the components folder. The intention of components is that it is a reusable set of patches that you can reuse for many different overlays. Instead of trying to apply the same patch in every overlay you can instead apply the component and keep features more modular.

You can see an example of how I use the components feature here:

https://github.com/redhat-cop/gitops-catalog/tree/main/openshift-ai/instance

[gferreir]

The architectural reasoning for the AAP 2.5/2.6 changes is clear. A few observations to complement @strangiato's review:

Typo in ConsoleLink text — will appear in the OCP UI

platform-instance/base/console-link.yaml has text: Ansible Automation PLatform (capital L). This will show verbatim in the OpenShift application menu once the ConsoleLink is applied.

"Logging infrastructure" copy-paste in two READMEs

Both eda-instance/README.md and platform-instance/README.md contain:

you can install Logging infrastructure by running...

This appears to be copied from the Logging Operator template. eda-instance should reference "the Event Driven Ansible Controller" and platform-instance should reference "Ansible Automation Platform".

automation_server_url in EDA: HTTP placeholder with no patch mechanism and no documentation

eda-instance/base/automationeda.yaml sets:

automation_server_url: http://aap-controller.example.com

Three compounding issues: the overlays/default/kustomization.yaml only includes ../../base with no patch for this field, so the placeholder lands directly in the cluster when a user runs oc apply -k eda-instance/overlays/default without further customization. The http:// scheme will fail in most environments where the Controller uses TLS. And the eda-instance README's Prerequisites section is empty — no mention that this field is required and must be replaced.

The result is a silently misconfigured EDA: it deploys without errors but can't run any automations. platform-instance documents the ConsoleLink patching requirement; the same treatment is needed here.

Minor: eda-instance/README.md has the title # Ansible Automation Platform instances — it should reflect EDA specifically (e.g. # Event Driven Ansible).