This is one instance of a general class of "Ansible sometimes wants Python (or other software) installed on the host system.

I don't think you meant "this action will fail" since it doesn't for me:

```
# cat /etc/yum.repos.d/ocp.repo 
[ocp]
baseurl=http://download.lab.bos.redhat.com/rcm-guest/puddles/RHAOS/AtomicOpenShift/3.5/2017-02-15.2/x86_64/os
gpgcheck=0
# rpm-ostree install python2-ruamel-yaml
...
Added:
  python2-ruamel-ordereddict-0.4.9-3.el7.x86_64
  python2-ruamel-yaml-0.12.14-9.el7.x86_64
  python2-typing-3.5.2.2-2.el7.noarch
Run "systemctl reboot" to start a reboot
# atomic host status
State: idle
Deployments:
  centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
             Version: 7.2017.86 (2017-02-15 18:38:23)
          BaseCommit: 82e655686424a6d2afc0f9b08c3e280bec98fc0b500f7710e6dbaac7573a2601
              Commit: b94d2fbe664e078fb3e48b777f18be5330f6a55d426d6742abe336823b9c2a90
              OSName: centos-atomic-host
            Packages: python2-ruamel-yaml

● centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
             Version: 7.2017.86 (2017-02-09 17:28:14)
              Commit: 82e655686424a6d2afc0f9b08c3e280bec98fc0b500f7710e6dbaac7573a2601
              OSName: centos-atomic-host
```

That said, AFAIK we're operating under the assumption we don't want OCP-on-AH to involve package layering.

Long term, I think the most maintainable solution would be enhancing Ansible to understand how to use a "tools container" with the host mounted at `/host`.  That's not going to be easy, but the payoff is we avoid polluting the host in every case.

Shorter term...One idea would be to teach the installer to operate out of a python venv or so.  There *has* to be some precedent for that in Ansible.

Yeah, this is fully supported in the current latest RHEL AH? Is there anything we need to do to ensure that the rpm-ostree change is re-applied during subsequent upgrades?

Layering persists across upgrades.  rpm-ostree is a fully atomic hybrid image/package system that continues to increase in flexibility and power.

That said I'm not necessarily saying we should go down this path - it's a big step.  And last time this came up the requirement for reboot was viewed as too onerous.  (We'll have live updates at some point but there are some things to work through).

It can be argued that it deviates from the immutable infrastructure model.

Anyways, I think we should involve some Ansible people here - and at least evaluate the difficulty of designing a mechanism by which the python library *doesn't* persist on the host.

Let's figure out how to track openshift-ansible + AH issues somewhere?  A tracker bug?  Upstream?  RH Bugzilla?  Both?

The biggest problem I see with the layered package approach is that the reboot requirement would force us to reboot after every package task we currently have. Obviously we can refactor things to be able to do the install steps as a pre-requisite task and it is something that we've wanted to do, it just hasn't been a major priority, yet.

I think a better path forward would be to decouple the requirement of the libraries to be installed on the host directly when a container runtime is available. In which case we would need an Ansible Connection plugin to be able to handle the logic. It should be possible to extend the ssh connection plugin to run a privileged docker/system container on the remote host. I suspect there may be some trickiness involved to ensure that environment, path, etc are handled properly, but it would decouple the dependencies from the remote host.

With the latest rpm-ostree, every time one does an `rpm-ostree install`, it's now cumulative with the previous "pending" deployment, so a reboot between each one is not required.

https://github.com/projectatomic/rpm-ostree/pull/611

Part of 2017.2.  (But doing layering all at once is still obviously more efficient)

Teaching ansible how to execute a container on the host seems like only 20% of the problem space - the 80% is ensuring that the task changes files in /host/etc, and not the container's /etc for example.  See https://github.com/ansible/ansible/issues/16782 for an earlier issue I filed.

So...are we basically at a point where unwinding the host dependency here is too hard at this point in the cycle, and we're proposing to add this python library to AH?

I'm not opposed to that, assuming we can make it temporary.  Basically, learn from this and build up openshift-ansible (and ansible's) tooling for using a tools container for things like this.

For this particular dependency we're going to fall back to PyYAML which is currently included in Atomic Host. We need to come up with a better long term solution though. I think the prevailing solution will be to provide a container with the required dependencies. This, as you said, is a general problem. We have other playbooks that require pyOpenSSL which is similarly not available on atomic host.

I'm fine with closing this bug unless you'd like to leave it open.

As part of our bug scrub on 3-May-2017, we decided we would close this BZ based on comment #11.