RFC: Enhanced Ansible support

[parlt91]

This RFC describes planned enhancements to the existing Ansible implementation in Uyuni

See the rendered version.

[rjmateus]

Overall looks good, but I have a few questions. Thank you for the great work

[meaksh]

Thanks Pascal for this RFC! I've just added some comments and clarifications

[cbbayburt]

Thanks, @parlt91. Looks good to me. All my concerns are already discussed under other reviews.

Here's a couple of remarks:

1. I think it's important that users have the exact list of the clients on which the playbook is executed. IIUC we'll store this in action details. This should be a hard requirement.

2. We should explore the formulas with forms UI to reuse as much as we can. Formulas UI also uses yaml to define the forms, so there's some opportunity there.

[parlt91]

@meaksh @rjmateus @admd I think I've addressed all your prior questions. Could you go through the RFC one more time and approve if you have no more questions? I'd like to start with development once I return from the bug squad ASAP.

[rjmateus]

LGTM

[admd]

Thank you Pascal

[HVSharma12]

Hi Team, I noticed that Uyuni currently uses the Salt ansiblegate module to communicate with the Ansible. Given that Ansible Runner is already available in Factory, has there been any consideration for using Ansible Runner?

Potential benefits of using Ansible Runner:

• Structured Logging: Playbook execution logs and results are stored in runner's artifact directory.
• Project-Based Configuration: Supports dedicated project directories for inventories, environments, and dependencies.
• Runner supports job timeout and failure handling via the settings file (idle_timeout, job_timeout).

I built an ephemeral Ansible Runner container for testing that:

• Runs playbooks and roles inside a containerized environment.
• Stores artifacts, logs, playbooks, and environments on the host VM.
• Requires only SSH access from the host VM to target nodes (no need to install Ansible on the host).
• Packages ansible, ansible-vault, ansible-runner, and dependencies inside the container.
• Allows commands to be executed directly from the host VM without requiring Ansible on the control node.

You can check out the setup here: https://github.com/HVSharma12/ansible-runner-container/tree/main.

Would it make sense to evaluate Ansible Runner as an alternative execution method as compared to using ansible command for Uyuni's Ansible integration, especially given the structured logging and project-based configuration benefits?

[meaksh]

Hey @HVSharma12, thanks for notes and feedback about ansible-runner!

As I mentioned in Slack, we didn't know about this way of operating Ansible, neither that users are frequently using this, i.a. in AWX. I see the benefits of enabling Salt's ansible modules to handle the Ansible executions via ansible-runner instead of the normal CLI interface.

This is definetely something we should explore and probably adopt, and I think it deserves its own RFC, something like Adding support for ansible-runner in Uyuni and Salt. This will require development efforts on the Salt side.

For now, the present RFC about the "Enhacement of Ansible support" is mostly around exposing more functionality to Uyuni from what we have already implemented, without much intervention on the Salt side.

I'd vote for preparing a separated RFC, describe the design, so hopefully we can agree on a proposal and go with the implementation it at some point.

[rjmateus]

thank you for your contribution @HVSharma12
I agree with Pablo, the current RFC is in the scope of giving more visibility and option to interact with ansible. But you proposal looks promising and I think we should research it after the current development effort.
@admd any comment on this?