I don’t think there’s going to be that many needs where the system will require a native binary module for speed reasons, though I would support patches that detected the file was binary and attempted
to /not/ process it or transfer it differently, I guess, if they were small and simple enough.
It’s just not something many people are going to use.
As for why we modify modules, there are definitely some things we do with modules to replace shebang lines on different systems (suppose one uses one python, another another, and one isn’t in the user’s path because we don’t trust the user) – this is the ansible_python_interpreter mechanism. What we do with our own python modules to embed arguments and optimize the way data is transferred in another story, this would be about the ‘non-newstyle-module’ code path.
Go-lang compiler makes a static-linked binary that includes all of the
required libraries. This means a module becomes more independent from
target hosts environment. No other files (such as libc.so) are
required to execute that module.
That's why I want to use go-lang for writing modules. speed is second
Anyway, thank you for accepting my concern.
I like the design principles of ansible-project and I keep on using ansible.
I am writing modules by python because I am familiar than golang (currently!)
However, I think this is not only golang specific issue.
On the ansible website[1], "any language is possible. " it includes C++.
Some people may want to write modules by C++ with existing libraries.
It should be possible to detect the module is binary and not look for the shebang in it, and otherwise treat it like a non-Python module in another language.
One thing that we /may/ wish to do is automatically send binary modules JSON, rather than the key=value legacy stuff it currently does by default (see “WANTS_JSON” in the code for the hack we did for the Ruby modules).
(I should aspect Go should have a decent JSON library available, right?)
Then the module would just need to look at argv[1] and read in that file as JSON and should be fine.
I would suspect there’s not a HUGE advantage to doing this, as while the module is now binary, the arguments file must be transferred seperately – I’d almost bet the Python method is still faster and you can still load C libraries from there.
I’m facing the exact same problem today.
I’ve developed a module in go (actually mainly because I know this language, and also because I’ve a bunch of library I’m using to connect to a specific backend).
Anyway, the module is running ok with the test-module utility (as described in the ansible documentation), but I’m totally unable to make it run within a playbook
The error is “module (mymodule) is missing interpreter line”.
I’m aware that this thread is more than 2 years old, but I cannot find any recent information on google and the documentation keeps on mentioning that it is possible to develop a module in any language.
Do you have any workaround to propose to use a binary module? Were you able to achieve your goal?
There is a pull request at https://github.com/ansible/ansible/pull/13771 to add support for binary modules. The plan is to merge it soon after 2.1 is released. Support for binary modules will be included in the 2.2 release.
