Arbitrary host expressions for Ansible backend

[amarao]

Ansible has extensive so-called host expressions: ability to join/exclude hosts from a host list based on logical expressions:

Examples:

• database,&primary - hosts in database and primary groups
• database,!standby - hosts in database group but not in standby group
• database[0] - first host in the group

Full list is here: https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html

testnfra lacked this ability for long time (see #609, rejected, where I was asked to bring patterns).

I've decided to try to implement them. Implementing from scratch is very hard (see link above to see all features and complexity). I've tried to reuse ansible code (specifically, InventoryManager, which allows evaluation of the host expressions). Proper support for InventoryManager also required to add ConfigManager (I wanted to keep full support for ANSIBLE_INVENTORY environment var which I use a lot for many testcases).

I understand, that bringing from ansible import .. could break a lot of things, so instead of 'switching to Ansible for everything', I've added a simple heuristic:

• older features (like normal groups and globs for host names) are going to work old way (keeping all existing tests running as before).
• Only if host expression is containing signs of complicated expression, switch to ansible. This will limit breakage due to possible ansible drift, only to tests, which are dependent on complex expressions.

Examples

testinfra_hosts = ["ansible://etcd(0)"]

def test_etcd_quorum(host):
    ...

tesinfra_hosts = ["ansible://node_exporter,!prometheus"]

def test_node_exporter_without_prometheus(host):
    ...

Host expression problem

I also found, that ansible://groupname[0] is not valid uri ([] is reserved for IPv6 addreses in the host part of the URI). I thought about possible workarounds, and the least invasive was to replace ansible://groupname[0] with ansible://groupname(0). Slightly odd, but perfectly readable and limited only to the specific case.

Limitations for possible characters in 'host' part of URI is also the reason why regexp (~) can not be supported this way, unfortunately.