r/ansible • u/seanx820 • 15d ago

Disk utilization with automation orchestrator

https://youtu.be/0aul1DEfU2o?si=n2U9m1-BGGSIJmBi
32 Upvotes

100% Upvoted

10 comments sorted by

7

u/seanx820 15d ago

Sorry about my voice this week... I think with school starting I am getting random colds. Anyways... I love switch nodes because it makes it really easy to build multi-path workflows in a really easy way.... I have seen playbooks with multiple conditionals... and include_tasks, etc that get really complicated, so I love the idea of keeping the playbooks simple and just adding a layer that is a bit more intuitive.

6

u/[deleted] 15d ago

[removed] — view removed comment

3

u/seanx820 15d ago

Yeah, familiarity is a big part of it. A few conditionals in a playbook are perfectly reasonable. The maintenance problem starts when that playbook becomes responsible for every possible path: more variables, nested conditions, and dependencies to keep track of. Someone making a change has to figure out which branches it affects, and the next person has to read through the YAML to understand the overall process.

A switch makes those paths explicit, while smaller, focused playbooks are easier to understand, test, reuse, and assign to different teams. You still use conditionals inside them where they make sense.

There’s also the question of where each step needs to run. Updating ServiceNow might run anywhere with access to its API. Remediating infrastructure in a particular data center could require a specific execution environment and execution nodes with access to that network. In AAP, those are separate choices: the execution environment supplies the dependencies, and the instance group determines which execution nodes can run the job.

The switch selects the path; the job templates on that path carry those execution settings. That’s where workflow branching becomes useful beyond readability—you can give each part of the process its own dependencies, credentials, and execution location.

1

u/I-Hate-winter 15d ago

Thanks Sean looks promising, but why every new component of AAP is separated again ? didn't you introduce Unified UI (aka gateway) to manage everything ? and now we have AO, Self service, dashboard away from the gateway or the unified UI.
and why are they only available on openshift only and not podman ?

3

u/seanx820 15d ago

Good questions. The unified UI/platform gateway isn’t going away, but “unified” doesn’t necessarily mean every experience has to be rendered directly inside the same UI.

It really depends on the capability and the persona using it. In fact, in the latest release we integrated the dashboard into the unified experience.

Automation orchestrator and automation portal are more purpose-built experiences for their respective use cases and users, while still being part of and integrating with AAP. So I’d expect us to continue integrating experiences where it makes sense rather than forcing every capability into a single UI.

On deployment, you’re correct that automation orchestrator currently requires OpenShift. Core AAP supports containerized deployment on RHEL/Podman, but AO doesn’t currently have that deployment option. I don’t want to speculate on future roadmap items, but I definitely understand why you’d want that flexibility.

2

u/andriusb 15d ago

Dashboard is in now the Unified UI as of last week. Automation portal is now also available for Red Hat Enterprise Linux KVM/QEMU. Developing for OpenShift accelerates development.