Issue 1:
ISSUE TYPE

Feature Idea

COMPONENT NAME

module_utils

ANSIBLE VERSION

ansible 2.3.2.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
python version = 2.7.13 (default, Jul 21 2017, 03:24:34) [GCC 7.1.1 20170630]

CONFIGURATION

No specific configuration

OS / ENVIRONMENT

N/A

SUMMARY

It does not seem that there is at present a way to have common code between plugins provided adjacent to a playbook or in a role. This can result in plugin files having a lot of common code which has to be maintained in multiple places. I think it would be beneficial for there to be a way of sharing code between plugins. This is possible (and common) within the packaged plugins and will help with the development of new plugins.

For modules, a modules_utils directory can be included adjacent to the playbook or inside the role which can then be accessed by custom modules to provide common functionality. This is extremely useful but does not work with plugins. Whether it is by making modules_utils inside action plugins or by creating some other directory for common code, I would like to see the

If I am not mistaken, plugins all run locally and modules run on the remote host. As such I assume that all module_utils are sent to the remote host. Given this, it may be beneficial to have plugin_utils which are only available to plugins and are hence not sent to remote hosts. This is not to say that module_utils shouldn't also be available to plugins to avoid the need for the same code in plugin_utils and module_utils.

STEPS TO REPRODUCE

I have created a small project which shows that the files under module_utils can be used

To run this sample, use ansible -vvv playbook.yml.

EXPECTED RESULTS

I would like the common code to be imported and for the module to run successfully with the following output for the second task:

TASK [Get the time using the plugin] ********************************************************************
task path: /home/flungo/developer/ansible/module_util_test/playbook.yml:5
ok: [localhost] => {
"changed": false,
"datetime": "2017-08-29 14:58:19.903485"
}

ACTUAL RESULTS

The import fails and so the module cannot be loaded:

ERROR! Unexpected Exception: No module named datetime_helper
the full traceback was:

Traceback (most recent call last):
File "/usr/bin/ansible-playbook", line 109, in <module>
exit_code = cli.run()
File "/usr/lib/python2.7/site-packages/ansible/cli/playbook.py", line 154, in run
results = pbex.run()
File "/usr/lib/python2.7/site-packages/ansible/executor/playbook_executor.py", line 153, in run
result = self._tqm.run(play=play)
File "/usr/lib/python2.7/site-packages/ansible/executor/task_queue_manager.py", line 288, in run
play_return = strategy.run(iterator, play_context)
File "/usr/lib/python2.7/site-packages/ansible/plugins/strategy/linear.py", line 203, in run
action = action_loader.get(task.action, class_only=True)
File "/usr/lib/python2.7/site-packages/ansible/plugins/__init__.py", line 358, in get
self._module_cache[path] = self._load_module_source(name, path)
File "/usr/lib/python2.7/site-packages/ansible/plugins/__init__.py", line 343, in _load_module_source
module = imp.load_source(full_name, path, module_file)
File "/home/flungo/developer/ansible/module_util_test/action_plugins/datetime_plugin.py", line 2, in <module>
from ansible.module_utils.datetime_helper import get_datetime
ImportError: No module named datetime_helper

Issue 2:
I suspect that @bcoca's atomic-copy changes in caf6bd6 can cause some unintended SELinux-related side effects. I've got a playbook that copies a file to the destination host:

Before:

[root@nagios limits.d]# ls -lZ
-rw-r--r--. root root system_u:object_r:etc_t:s0 90-nproc.conf
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0 riak.conf

After:

[root@nagios ~]# ls -lZ /etc/security/limits.d/
-rw-r--r--. root root system_u:object_r:etc_t:s0 90-nproc.conf
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 riak.conf

This particular change actually breaks root login and I suspect it's because of the change in SELinux security context from "etc_t" to "admin_home_t".

I don't really know enough about SELinux to comment more extensively on this. I hope someone else can shed some light.