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.
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.
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.