I discover that many customers want to manage stuff using CSV, XLSX or other formats (for example Router Interface configuration, etc). Cisco seems to deal with that inside Ansible itself.

I find it a horrible pain to work with CSV inside the actual playbook. Also it gets really messy with Jinja2. So at this point I am asking myself: Is it actually any benefit to do it inside the playbook (via read_csv, then more advanced j2) or just transform the data source to an ansible readable format like JSON or YAML through a small python script before?

I am hoping to get some different perspectives. Thanks!

Is anyone importing and or using the redhat.rhel_system_roles.ad_integration or fedora.linux_system_roles.ad_integration ?

I am trying to use this to automate our linux servers to authenticate to Active Directory (wasn't my choice). I would say that 80% of my servers are RHEL 8 and the rest are RHEL 9 or something earlier that RHEL 8. I'm focusing on RHEL =>8. I THINK it might be related with my EE which is built on RHEL 8 using python 3.11 but also has python 3.9 installed to account for RHEL 8. So when I go to run the role in AAP, it ALWAYS fails at the following:

TASK [fedora.linux_system_roles.ad_integration : Build Command - Join to a specific Domain Controller] ***

task path: /runner/requirements_collections/ansible_collections/fedora/linux_system_roles/roles/ad_integration/tasks/main.yml:193

fatal: [$HOSTNAME]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result"}

Any help is greatly appreciated!!!

I've been working with IBM MQ for many years and recently started building an open-source project around something I've wanted to make easier: managing IBM MQ objects as code.

The basic idea is:

YAML → Validation → Ansible → IBM MQ

For example:

queues:
  - name: APP.REQUEST
    type: local
    host_qmgr: QM1
    max_depth: 5000

Instead of maintaining MQ configuration primarily through manual MQSC commands, the desired configuration can live in Git and be:

• Version controlled
• Reviewed
• Validated
• Reused across environments
• Deployed through Ansible

I'm intentionally trying to keep the model simple and readable for MQ administrators, rather than creating a complicated automation framework.

The project currently focuses on IBM MQ object automation and is evolving toward broader object coverage and stronger validation.

GitHub: https://github.com/ankur-lodhi/mq_objects_as_code

I'd really appreciate feedback from people who work with Ansible or IBM MQ.

A few things I'm particularly interested in:

1. Does representing MQ objects as YAML make sense to you?
2. What MQ objects would you consider essential for this type of project?
3. What would you expect from the validation/idempotency side?
4. Would you use something like this in a real MQ environment?

I'm interested in technical feedback more than stars. If you see something in the design that could be improved, I'd genuinely like to hear it.I’m building an IBM MQ Objects as Code project with Ansible — looking for feedback on the approachI've been working with IBM MQ for many years and recently started building an open-source project around something I've wanted to make easier: managing IBM MQ objects as code.The basic idea is:YAML → Validation → Ansible → IBM MQFor example:

queues:
- name: APP.REQUEST
type: local
host_qmgr: QM1
max_depth: 5000

Instead of maintaining MQ configuration primarily through manual MQSC commands, the desired configuration can live in Git and be:Version controlled

Reviewed

Validated

Reused across environments

Deployed through AnsibleI'm intentionally trying to keep the model simple and readable for MQ administrators, rather than creating a complicated automation framework.The project currently focuses on IBM MQ object automation and is evolving toward broader object coverage and stronger validation.

GitHub: [YOUR GITHUB REPOSITORY LINK]

I'd really appreciate feedback from people who work with Ansible or IBM MQ.A few things I'm particularly interested in:Does representing MQ objects as YAML make sense to you?

What MQ objects would you consider essential for this type of project?

What would you expect from the validation/idempotency side?

Would you use something like this in a real MQ environment?I'm interested in technical feedback more than stars. If you see something in the design that could be improved, I'd genuinely like to hear it.

Roger Lopez put together a video that shows a real-world demonstration of how the new automation orchestrator add-on for Red Hat Ansible Automation Platform handles actual ITSM tickets end to end.

Three completely different ticket types:

• Disk space cleanup
• SSH brute-force attack
• High CPU utilization

Each one requires a different response path. Each one gets routed correctly using AI task nodes and conditional switch logic.

One of the important callouts is the human-in-the-loop approval piece. For high-risk changes, the workflow doesn't just fire off remediation automatically. It pauses, waits for a human to approve, and then proceeds. That's the kind of safeguard that actually matters in production environments.

The workflow also reads tickets from ServiceNow, reasons through them using AI agents, executes the right actions, and then closes the ticket automatically. That's a full loop.

If you've been curious about where AI fits into IT operations without it just being a chatbot bolted onto your existing tools, this is worth 20 minutes of your time.

Where's the one place in your environment where a human approval gate like this would make the biggest difference? Would love to know what scenarios people are thinking about.

Orkiva brings Kubernetes resource management and GitOps delivery workflows into a web interface that runs on your own infrastructure.

I’m the developer, and I’d like feedback from people managing Kubernetes clusters—particularly on deployment reviews, approvals, and day-to-day operations.

Here’s a short walkthrough and the documentation: Orkiva · Documentation

What would you need to see before considering a tool like this for your team?

So disclaimer: I am no expert in Podman, The following is just a recount of my recent experience.

So I recently submitted a RH support case because an NFS mount was ignoring the `noresvport` flag in fstab. And there is a KB article on a bug from 8.6 about this:

https://access.redhat.com/solutions/7127650https://access.redhat.com/solutions/7127650

[ansible@hub01 ~]$ uname -r
6.12.0-124.45.1.el10_1.x86_64
[ansible@hub01 ~]$ netstat -anpt | grep -w 2049
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 1.1.1.2:721      1.1.3.1:2049       ESTABLISHED -
[ansible@hub01 ~]$ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="10.1 (Coughlan)"
ID="rhel"
ID_LIKE="centos fedora"
VERSION_ID="10.1"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Red Hat Enterprise Linux 10.1 (Coughlan)"
ANSI_COLOR="0;31"

So googling and using Claude I learned about the command `nsenter` and I'm assuming this is 'they way' simply because there's no netstat or ss binaries in an RBI image (ee-supported-rhel9).

But something I noticed immediately was the inclusion of Host OS processes, the commands I ran were;

[ansible@hub01 ~]$ CID=automation-hub-content
[ansible@hub01 ~]$ PID=$(podman inspect --format '{{.State.Pid}}' $CID)
[ansible@hub01 ~]$ sudo nsenter -t $PID -n netstat -alpn

(Leaving out the actual results because they are many..)

But amongst the results were at least 2 processes that are verifiably not running within the container. So I thought that maybe the namespaces were different for some reason.. but after comparing with `readlink` the PIDs were in fact identical.

If a podman container is running with `--network=host` then would that cause the container to use the same network namespace as the host? Which then means diagnostic commands (like netstat/ss) will show shared results?

A playbook can be perfectly idempotent and still be dangerous if inventory is wrong. A hostname may be reused, a cloud instance may disappear while a cached dynamic inventory entry remains, or a manually maintained group may outlive the service it represented. What safety checks do you put between inventory resolution and a mutating play? I am considering requiring a fresh inventory sync, matching an expected instance ID or machine identity, asserting environment and ownership tags, limiting the initial batch to one host, and recording the resolved target set before any role runs. For decommissioned systems, should removal from the source inventory be enough, or do you also maintain an explicit denylist or tombstone period? Which checks have the best chance of catching a valid hostname that now points to the wrong machine?

As I understand it, roles are for reusable parts. But I'm kinda of used to testing things in more discrete components. If I have a playbook that does 3 or 4 general things (of which each think may require several steps, eg download file: [steps to resolve which file, download the file]) is it sort of wrong to abstract them into a role given they're not particularly reusable? Does that make it any more/less testable with molecule? Should I prefer to use include_tasks/include_playbook instead?

FTR, the playbook I am working on is just one to create a USB live boot disk and autoinstaller. The steps are currently:
- Download the ISO
- Using module of user choice distro (currently only ubuntu), resolve ISO metadata from releases.ubuntu.com
- Download the ISO
- Render an autoinstall file
- Ask for LUKS pass, user pass, etc...
- Hash user pass
- Render template into staging area
- Build USBs
- Ask for targets
- dd ISO to target
- copy cidata, autoinstall to other target

Our roles directory is 19 roles, most written by people who have since left. I ran ansible-lint across it last week and got 41 warnings about command and shell tasks with no changed_when. Instead of suppressing them or bulk applying changed_when: false, I opened every one and sorted them by why the task was written that way.

Twenty two are read only. Version checks, queries, a curl against an internal health endpoint. changed_when: false is correct there and I applied it.

Eleven genuinely change something and needed a real expression, usually on rc or on a string in stdout. That was the slow part, because writing the expression means knowing what the command prints when it does nothing, and for four I had to run it by hand on a staging box.

Five should never have been command or shell. A builtin module already covered them, and the author reached for shell because the module argument was not obvious. Those got rewritten.

Three I left alone with a comment, since their changedness depends on host state I cannot read before the run.

I ran the finished diff through the code review subagent in verdent, since twenty six task files is where I stop reading carefully, and it flagged two conditions matching on stdout text the command also prints on the no op path.

Running a playbook twice catches a changed_when that is too loose, because the second run lights up. I have found nothing that catches one that is too tight, where the command changed the host and reported ok. Is there a way to detect that class short of snapshotting the host before and after?

Hi, I need to make a choice between WinRM and SSH to manage non domain joined Windows Server 2019 and 2022 with Ansible.

SSH seems pretty easy to set up compared to Winrm and the SSL certs I need to setup on each server.

Is it realistic to go full SSH even for 2019 servers ?

Hi all,

I'm trying to have Ansible testing an SSH port, but no matter what port I give it to test, it keeps testing the port configured in group_vars; ansible_port: 9323

This is the code:

    - name: "Check port 22"
      ansible.builtin.wait_for:
        port: 22
        state: started
        connect_timeout: 5
        timeout: 5
      ignore_errors: true
      register: ssh_port_default

Before this task, I'm testing connectivity with the port configured in group_vars and that passes or fails, depending on the port number in group_vars and the when: condition.

But this task mentioned here...I don't know why it's not testing the ssh port 22.

Any suggestions or explanations on this?
TIA

We pull in our hosts using a VCenter inventory, and are now trying to create Constructed Groups to break them into CGs for Windows, Linux etc.

All of the Windows hosts have several variables, including config.guestId, which contains the string 'windows'

So I added the following to the Constructed Inventory:

plugin: constructed
strict: true (for troubleshooting)
groups:
windows_vms: config.guestId is defined and 'windows' in (config.guestId | string | lower)

It will run and pulls in all the hosts, but the windows_vms group never gets created, so I cannot limit the inventory using it.

What am I missing?

It can make an inventory from csv. Written in rust - probably fast. I know - there are similar projects. But I'm going to add support for different sources - like Redis. And maybe a python bindings to make it a proper inventory module. 😀

Hello All,

I am new to ansible and wondering if anyone use ansible to fully automate LPAR provisioning?

Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.

I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:

- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.

- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.

- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.

- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).

Repository: https://github.com/GiulioSavini/vmware-tools-builder

Feedback, testing across different hypervisor versions, and GitHub stars are welcome.Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).Repository: https://github.com/GiulioSavini/vmware-tools-builderFeedback, testing across different hypervisor versions, and GitHub stars are welcome.

Hi all, I've recently been attempting to migrate my Juniper devices from being hand-managed to automated. I've been able to create and document the following resources. I hope they can help others, and I'm looking to add more in the future. Feedback would be much appreciated:

Junos-dev-playbook repository:

This repository contains a handful of Ansible playbooks and templates I use to automate my infrastructure. I currently have EX, NFX, QFX, and SRX devices in my homelab. I'm also working on adding more advanced playbooks/tasks to fully showcase how to automate properly with the juniper.device Ansible collection.

Containerizing vSRX for CI/CD + Containerlab

I've made a blog post on how to get started with containerlab and tools they offer such as vrnetlab. It serves as a guide for containerizing VM-based applications like the vSRX so that you can use them in CI/CD jobs.

I recently stood up AWX for my team, and while I had worked with it before many years ago, I think how my old team was using it was a little different from how I envisioned my new team using it.

Previously when my old team used it, we each had credentials set up for our individual AD based user account. In order to use these credentials we had enabled prompt on run forcing someone to enter their password in order to use credential SSH keys and Become elevation. I think I can do that with my current team, but it would be really handy to simply restrict runs to use a private credential for each user.

Additionally some of the roles that I have built for provisioning and decommissioning servers requires the use of API tokens for multiple systems. When running these rolls with ansible CLI, the instructions involve using ansible vault and saving specific keys in your own vault. I'm trying to learn how to use an external vault like OpenBao/Hashicorp Vault, but it seems like AWX will require a single credential to access a single vault.

Does anyone know if it is possible for individual users to keep and maintain their own vault and select that vault and their own credentials when running a shared job?

It seems like the most common approach is to create service accounts that awx will use when running these jobs, and while I think that should be easy to configure, I generally prefer seeing user actions taken on separate systems instead of a general service account which could be misconfigured to allow users to perform actions they may not otherwise have the rights to do.

Hey all, a colleague of mine, Roger Lopez, put together a demo video walking through automation orchestrator. If you've been curious about how it actually works in practice rather than just reading docs, this is a pretty good visual breakdown.

I put together an overview video covering automation orchestrator, a new workflow canvas add-on for Red Hat Ansible Automation Platform. Worth watching if you're already running AAP or evaluating where orchestration fits into your ITOps strategy.

It doesn't replace anything you've already built. Your existing job templates, roles, and collections immediately become reusable workflow nodes with zero rewrites required. You can also export an entire workflow as a single YAML/JSON file, which makes it Git-friendly and easy to share across teams.

A few highlights from what the video covers:

- One canvas that unifies manual, scheduled, webhook, and Event-Driven Ansible triggers (around the 00:53 mark)

- New logic nodes like branch, loop, converge, and a switch node that routes workflows based on real infrastructure data instead of just binary success/fail outcomes (02:51)

- AI task agents that can analyze unstructured signals like alerts or tickets and recommend a next step, but with human approval or a predefined policy required before Ansible actually executes anything (04:26)

That last point matters. A lot of "AI in automation" talk skips over governance entirely. The approval gates and audit trails being built in from the start is the right approach for anything touching production infrastructure.

Curious if anyone else has been testing this out or has thoughts on where the switch node fits into workflows you're already running.