Ansible Golang Modules and sanity checks

Hi folks,

We are developing an Ansible collection in which our modules are written in Go.

This brings several benefits that align directly with the goals of the collection (VMware and OpenStack bindings), but also benefits Ansible modules execution in general. For example, runtime performance is significantly improved with these small, compiled binary modules.

Last week, I proposed a PR to Ansible Core to extend the sanity checks to support Go modules: validating JSON input/output for Go-based modules, checking the Go file skeleton, ensuring the module documentation matches the Go module arguments, and so on.

The goal is to avoid having to skip all sanity checks, especially since this is a certified collection.

I’m opening this thread for several reasons.
First, I’m curious whether there is interest and usage of Go with Ansible.
Second, I’m wondering whether we could contribute to the documentation or help write guidelines for developing and using Go-based modules. Finally, I’d like to know if there is any interest in creating a third-party testing tool specifically for Go modules.

Thank you in advance for your thoughts and feedback.

2 Likes

It shouldn’t be certified if it contains Go modules, as noted in https://connect.redhat.com/sites/default/files/2025-06/Ansible-Certification-Workflow-Guide202506.pdf :

The Collection must not contain any binary files. Only plugins written in Python or
Powershell will be certified.

3 Likes

Hello Mathieu [ @matbu ], :waving_hand:

I think your idea is interesting. But the efforts and impacts must be carefully considered and evaluated in advance. Basically I think that considering of further integration scenarios in Ansible, in this case the Go programming language, is worth looking into. Even if we only look at it from a high level of abstraction. If it is permitted I would like to redirect your attention to another perspective.

One particular difficulty I see with this approach is the use of compiled binary modules to improve performance. I am not a Go expert, but I assume these depend on the architecture they were compiled for, i.e. x86, arm, ppc, etc. This raises an important question for me: How did you solve the problem of using the right binary modules in a heterogeneous system landscape with different architectures? Perhaps you could simply describe how you solved this challenge.

That is a fundamental question for me. For me one valuable advantage of Ansible is the use of Python source code and therewith the independence from architecture. Binary modules can speed up automation processes from a performance perspective, but they can also make them significantly more complicated to use.

I am aware that this point of view goes in a completely different direction than your suggestion. In my opinion there should be a coherent approach here to convince users of the added value.

Thanks and best regards
Stefan

Using the right binary should be relatively easy: use an action plugin that determines the target’s architecture (and calls ansible.builtin.setup to figure it out if it hasn’t already), and picks the matching binary module file.

In os_migrate.vmware_migration_kit, which seems to be (one of?) the collection in question, there is no action plugin though (vmware-migration-kit/plugins at main Ā· os-migrate/vmware-migration-kit Ā· GitHub), so I guess the collection is specific to one architecture?

1 Like

I guess the rules are outdated then :slight_smile: Thanks for linking that document, I always wanted to look at it, but didn’t knew where to find it.

1 Like