Got Ansible own modules? Run them from within the Salt just like that! #43504
What does this PR do?
In case you want to migrate away from Ansible, but have already modules written for it — no worries. Just toss them in and run them from Salt and Salt states.
Currently, only Python-written modules are supported. Support for other languages are still in progress.
The entire Ansible should be installed on the Minion. No remote execution at the moment. Continuation of this work can pull required files from the Ansible through the Salt transport. These files should be installed on Master only (in a future) and then thus get executed on the Minions.
Description and Usage
Normally Salt modules are usually
If you use typical development environment, this will result to the following:
Listing available Ansible modules
In order to list all available Ansible modules, call
To filter them out, just type a string that matches inside them, e.g. "linux":
Getting more information about the module
You can read all the details about any Ansible modules by issuing
At this point you may ask for
Calling Ansible modules
Calling Ansible modules are just like any other Salt modules, straight-forward, except they will be needing to stay within their own namespace, which is different than we are using typically in Salt:
Calling from the SLS files
That is also supported. Naturally, you can use typical
task_id: # ID of your task ansible.call: # Mandatory. This calls the modules - namespace.module: - params - namespace.another.module: - params - some: keywords
For example, this state will fail, because
run_test_echo: ansible.call: - system.ping: - data: "Hello from Salt" - network.junos.junos_package: - foo.bar:
This results to the following output:
Please review Salt's Contributing Guide for best practices.
This is awesome!
My main concern here is the departure from the
How do you feel about that, @isbm ?
@cachedout I feel not very well about.
On the other hand, why not depart anyway? Modules in Salt are
Alas, when the entire community will still start cry "Nah, no, we do not want stick to the Salt spirit and do
Personally I do not like the departing from the module.function model. We already have other similar things that work with the whatever.call model.
Between the salt module
And the way that most proxy minions are written.
We already have this kind of behavior in place.
My 2¢, Thanks.
@gtmanfred It is not a runner module, and the paradigm is different. When an Ansible module is called, it is called like being a part of Salt (this is a migration feature, not just generic execution implementation), while in your examples parameters are passed to somewhere else towards generic function target.
And even your example isn't the best one as it would be better to incorporate there the model I propose. Alongside of the weird path
And yes, unfortunately we have
This is what happens on the Ubuntu 16:
Different exception content?.. Maybe it will go away if I try now to see if the exception is raised at all. But this will kind of make the test a bit "dull" (too generic). Still I don't know how this env will react, since I am "poking the sky", in a hope it won't fail.