What's New in Red Hat Ansible Engine 2.8

May 29, 2019 by Chris Short


Red Hat Ansible Engine 2.8 is now available. This release features many improvements and enhancements (please refer to the CHANGELOG for more details). Also, new features worth highlighting here are Ansible content (Collections), BECOME being the default privilege escalation path, no longer depending on paramiko, and BECOME plugins, and other notable improvements and changes.

The future of how Ansible content is handled

The Ansible community is excited to provide new modules and plugins for Ansible users. This keeps Ansible maintainers busy; merging new code into repositories as fast as a team can. Occasionally, things get left behind. Content that could have been released ends up waiting for the next Ansible Engine release. Currently, the official Ansible Engine release process is the only way for users to utilize or consume new content easily.

As such, the Ansible community has begun the journey of providing our users with more flexibility to create and consume content. In Ansible Engine 2.8, modifications are in place for how Ansible Engine handles content not delivered in the official release. These changes allow for the creation of a new delivery method to users. This delivery method should not depend on Ansible maintainers to manage content as well as the platform code.

In future releases, we plan for content Creators to be able to provide their content in a package format called a Collection. Collections will be able to be “installed” in the appropriate location for execution whether that’s on the Ansible control node or the managed node. The Collection Creator will be able to provide execution details via roles and playbooks in the package itself. The before mentioned changes to Ansible Engine will allow Collections to be one way to detach content from the official Ansible Engine software delivery process.

Please stay tuned for more details to follow in the coming weeks.

Welcome Become

Become has been around for a while. Beginning in version 2.8, by default Ansible Engine will use the word BECOME to prompt for a password for elevated privileges (sudo privileges on *nix systems or enable mode on network devices). Think of BECOME as the generic privilege escalation path that has some awareness of the systems involved.

Example usage:

ansible-playbook --become --ask-become-pass site.yml
BECOME password:

Ansible Engine 2.8 brings BECOME plugins too. Plugins like doas (Linux) and runas (Windows) allows automation to be executed by a specific user. The enable become plugin should be familiar to network engineers old and new as it allows for elevated permissions on a network device.

Python interpreter discovery

Have you ever seen this error?

/usr/bin/python: bad interpreter: No such file or directory

In previous versions of Ansible Engine, Ansible defaulted to /usr/bin/python as the default Python interpreter. Starting in Ansible Engine 2.8, Ansible searches for the correct path and executable name for Python on each target system, first in a lookup table of default Python interpreters for common distros, then in an ordered fallback list of possible Python interpreter names/paths. For more information on the technical details of this please refer to the Ansible 2.8 porting guide.

Other notable enhancements

Retry File No Longer Created by Default

When was the last time you searched your filesystem for .retry files? If you’ve used Ansible long enough you probably have a few lingering around. Starting with Ansible Engine 2.8, the default setting will no longer create retry files. The behavior can be modified to previous versions by editing the default ansible.cfg file.

Play Recap Updates

Per the Ansible 2.8 porting guide:

Play recap now counts ignored and rescued tasks as well as ok, changed, unreachable, failed and skipped tasks, thanks to two additional stat counters in the default callback plugin. Tasks that fail and have ignore_errors: yes set are listed as ignored. Tasks that fail and then execute a rescue section are listed as rescued. Note that rescued tasks are no longer counted as failed as in Ansible 2.7 (and earlier).

The end of your playbook runs (Play recap) will have some new columns for skipped, rescued, and ignored hosts:

Screen Shot 2019-05-22 at 14.33.42-1

Clouds and Containers

There are also enhancements and additions to cloud and container modules to include Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman, and kubevirt. It should also be worth nothing, TOML files can now be used as an inventory source.


Are you using Red Hat Ansible Network Automation? Ansible Engine 2.8 will no longer provide or have a dependency on paramiko. Ansible Engine will use ssh by default. If paramiko is required for an environment, please install it using: pip install paramiko

Looking for support related to paramiko via a Red Hat subscription? Please see Red Hat Customer Portal Solution: Paramiko package missing after new Ansible Engine installations


Please join us for our What's New in Ansible Automation webinar on June 4th at 2PM EDT to hear about the latest updates to Red Hat Ansible Tower as well as Red Hat Ansible Engine.

If you'd like to learn more about Collections, please join us for The future of how Ansible content is handled webinar on June 13th at 10:00AM EDT.


Join us September 24-26, 2019. We will follow the same format as last year with a Welcome Party on the evening of September 23, two days of content on September 24-25, and some add-on options, like workshops, on September 26. Sign up for AnsibleFest announcements so you don’t miss any of these important dates. And don’t forget for those who want to tell their awesome Ansible Automation story, to submit your talk during our open Call for Proposals for AnsibleFest Atlanta here. The CFP will close on June 4, 2019.


Ansible Engine


Chris Short

Chris Short has been a proponent of open source solutions throughout his over two decades in various IT disciplines including systems, security, networks, and DevOps engineering and advocacy across the public and private sectors. He currently works on the Ansible team at Red Hat. Chris is a partially disabled US Air Force veteran living with his wife and son in Greater Metro Detroit. Chris writes about DevOps and other topics at chrisshort.net. He also runs the DevOps, Cloud Native, and open source focused newsletter DevOps’ish.

rss-icon  RSS Feed