See discussion here:

https://lists.fedoraproject.org/pipermail/devel/2015-October/215740.html

In the cloud group we have 2 options:

• install py2 and some common libraries that will take care of most ansible modules
• educate people on how to bootstrap to get python installed so they can use ansible (can use ansible 'raw' mode for this)

For Atomic we'll have to figure out something because we can't just install our dependencies in atomic.

I like the installation of py2 route (as atomic seems to have done) :-) but I know that it can be a problem for projects worried about space. So some information on ansible's raw module to help out with bootstrapping if that's what you decide to go with:

http://docs.ansible.com/ansible/raw_module.html

The raw module exists to bootstrap a remote environment to be able to run ansible modules there at all. It can basically be used to invoke shell commands on the remote host without some of the niceties that the command and shell module give you (because with them, we have python installed on the remote host so we can do more complex things.) If your environment has a system package manager then you want to do something like:
{{{
(ad hoc mode):
ansible CLOUDHOST -m raw -a 'dnf install -y python2 python-dnf'

(from a playbook):

• hosts: CLOUDHOST
  tasks:
  • raw: dnf install -y python2 python-dnf
  • dnf:
    state: present
    name:
    • OTHER_PACKAGE_FOR_IMPORTANT_MODULES
    • ANOTHER_IMPORTANT_PACKAGE
      }}}

I would consider python2 (which is the only thing we document upstream as essential for everything) and the python modules to get the ansible module for your package manager running are the two most essential things. You could also recommend that people install things like the python2 selinux bindings since some pretty basic modules depend on it but you could also make that a second step using the dnf module if you like.

We (upstream ansible) would be willing to host some documentation with our other docs on getting ansible to run on distros that don't have python3 by default if you want to write it or we could link to documentation that you write on your own infrastructure if you want. Let us know if you want us to help out in that way. I'm abadger1999 on irc.freenode.net. The other devs and I tend to hang out in #ansible-devel.

Not sure about the best thing for atomic... Some people tend to install and run their remote ansible via pip and virtualenv. That might be a possibility but that may also just be substituting one set of space requirements that you'd like to get rid of with another. It would be good to install enough libraries by default that basic things work (for instance selinux bindings since these are fedora hosts). beyond that maybe you could document how to add packages to the atomic images from the machine hosting them via ansible? Not sure if that's the right idea but it's one possibility.

In case it helps, here is the role I've been using for F23.

{{{

Installs Python 2 and the libraries needed by Ansible modules.

• name: install python 2.7
  raw: sudo dnf install -y python2

• name: collect facts
  setup:

• name: install dnf-python
  when: ansible_pkg_mgr == 'dnf'
  become: true
  become_user: root
  command: dnf install -y python-dnf
  register: dnf_install_python_result
  changed_when: '"Nothing to do" not in dnf_install_python_result.stdout'

• name: install dnf packages needed by ansible
  when: ansible_pkg_mgr == 'dnf'
  become: true
  become_user: root
  dnf: name={{ item }} state=present
  with_items:

• libsemanage-python
• libselinux-python
• python-dnf
• python-firewall
  }}}

Blogged about this on Fedora Magazine platform

https://fedoramagazine.org/getting-ansible-working-fedora-23/

FYI, you could also use [https://cloudinit.readthedocs.io/en/latest/ cloud-init] script (in user-data of the cloud provider) to install additional packages on the machine. Also a lot of other configuration is possible. That would allow you on start-up to have things already in a good state.

The advantage is that you still have the small cloud base image. Everybody would think that just that one other package is enough to have base image complete. But if you take into account all these use cases, you'll end-up with a bloated image.

There is also a porting effort for getting ansible be python3 ready. Ansible 2.2 is gonna aim to get the controller run on python3, but Toshio is also looking at python support on the remote side and we did a bit of work to support it the last days, by porting the existing snippets to python3, and wrote that doc https://github.com/ansible/ansible/blob/devel/docsite/rst/developing_modules_python3.rst