Using ansible modules as normal python modules

[Steven Kryskalla]

Hello,

I did a small experiment with turning the ansible "library" modules
into python modules that can be imported and used from normal python
code and wanted to see what other people think. Here is a demo of what
it does:

https://github.com/lost-theory/ansible/blob/module_experiment/demo.py#L35

The changes are in this branch:

https://github.com/lost-theory/ansible/commits/module_experiment

My reason for doing this is that I think the code inside the modules
is very useful, and it would be nice to import, extend, run, etc. from
other python code. Right now they are sort of locked into running from
the command line in a specialized way (INCLUDE_ANSIBLE_MODULE_COMMON,
hardcoding arguments into MODULE_ARGS, etc.). There was a mailing list
post from a few days ago where some folks were asking for something
similar:

https://groups.google.com/forum/?fromgroups=#!topic/ansible-project/7SByPqJxa7Q

Some examples of things that would make this easier and would not
disrupt the "language agnostic" goal too much:

1. move the "main()" call that is currently at the bottom of every
module into an "if __name__ == '__main__'" block.
2. use return values and exceptions instead of calling exit_json or
sys.exit directly
3. import module_common.py instead of writing its contents into each module
4. allow for arguments to be passed into a module in a programmable
way instead of the hardcoded MODULE_ARGS "constant"

Would patches be accepted for those kinds of changes? Or is there a
better way to do this kind of thing?

thanks,
Steve

[Michael DeHaan]

I am generally fine with modules being adapted to call exceptions and then have catchers that call exit_json and so on, but it doesn't bring me all that much benefit.  In fact, it makes the code more complicated.  Where as, right now, module.exit_json is a very nice abstraction.

Importing module_common also doesn't make sense, as we've then transferred an extra file with an extra operation, where the entire goal was to keep the number of operations super-low.

Embedding arguments versus calling them on the command line was also a design decision that allows for complex argument transfer.

Ultimately I don't see the benefit right now.

If some other code wants to use Ansible, it can go through the Ansible Runner API and get to all of the benefits.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Steven Kryskalla]

On Monday, April 8, 2013 8:44:53 AM UTC-7, Michael DeHaan wrote:

I am generally fine with modules being adapted to call exceptions and then have catchers that call exit_json and so on, but it doesn't bring me all that much benefit.  In fact, it makes the code more complicated.  Where as, right now, module.exit_json is a very nice abstraction.

I see.

Importing module_common also doesn't make sense, as we've then transferred an extra file with an extra operation, where the entire goal was to keep the number of operations super-low.

If you create 10 users, that requires 10 file transfers of the user module (including 10x duplicate common code), right? Seems like factoring out module_common and passing in arguments would get that down to ~2 file transfers with each file being smaller.

 

Embedding arguments versus calling them on the command line was also a design decision that allows for complex argument transfer.

I see, but I don't think it's the only way. You could pass in complex args as a JSON string on the command line, or pipe the JSON into the script, or write the complex args to a file, or store the JSON string in an environment variable, etc.

 

Ultimately I don't see the benefit right now.

If some other code wants to use Ansible, it can go through the Ansible Runner API and get to all of the benefits.

 Thanks I will take a look at that.

-Steve