tl;dr The problem is that Ansible, at least in 2.3.3.0, lazily evaluates the templated random_conductor variable in the delegate_to field twice in running os_nova's "Perform a cell_v2 discover" and if it differs between the two evaluations, which is possible because random_conductor uses the "random" filter, then Ansible can't use the remote address stored in inventory for the delegated host and falls back to using just the inventory name for ssh which fails if ran on a non-openstack-ansible-deployed host where openstack-ansible hasn't added the inventoried hosts to /etc/hosts.

Steps to reproduce:
1. Create an openstack-ansible deployment environment that contains multiple nova-conductor containers (ie multiple infra hosts).
2. Deploy openstack-ansible (ie "openstack-ansible setup-openstack.yml") from a host that openstack-ansible is not deploying to (ie one that doesn't have the openstack_hosts role or in inventory at all; eg *not* an infra node which seems to be a common use-case).
3. The failure will occur with (N-1)/N probability where N is the number of nova-conductor containers (because that's the odds of randomly selecting a different nova-conductor than the first one selected).

Disclaimer: The failure only occurs with (N-1)/N probability, where N is the number of nova-conductor containers.

Symptoms:
1. os_nova's "Perform a cell_v2 discover" task will fail.
2. A nova-compute container will be reported by Ansible as "unreachable".
3. With "-vvvv", "ssh: Could not resolve hostname <insert nova-conductor container name here>: Name or service not known" is reported by Ansible during os_nova's "Perform a cell_v2 discover" task.
4. With ANSIBLE_DEBUG=1, "no remote address found for delegated host <insert nova-conductor container name here>\nusing its name, so success depends on DNS resolution" is reported by Ansible during os_nova's "Perform a cell_v2 discover" task.

Work-around:
1. Change `delegate_to: "{{ random_conductor }}"` to `delegate_to: "{{ hostvars[random_conductor]['ansible_host'] }}"`.
1. Deploy openstack-ansible (ie "openstack-ansible setup-openstack.yml") from an openstack-ansible deployed node (eg an infra node).
2. Populate /etc/hosts with inventoried nodes (eg run /var/tmp/openstack-host-hostfile-setup.sh)

Explanation:
1. random_conductor is templated as "{{ groups[nova_services['nova-conductor']['group']] | random }}".
2. Ansible lazily evaluates this twice:
2a. When fetching the host vars for the delegate_to host; see "delegated_host_name = templar.template(task.delegate_to, fail_on_undefined=False)" in ansible/vars/__init__.py, _get_delegated_vars().
2b. When setting the delegated host for the task; see "delegated_host_name = templar.template(task.delegate_to)" in ansible/playbook/play_context.py, set_task_and_variable_override().
3. The lazy evaluation of the "random" filter introduces a 1/N probability that the delegated host vars match the delegated host.
4. When Ansible looks for the delegated host's remote address (ie ansible_ssh_host or ansible_host) in the play's delegated host vars and doesn't find it (because Ansible only populated the delegated host vars with the previously lazily evaluated inventory name), then it falls back to using the host's inventory name hoping system-based hostname resolution (eg /etc/hosts, DNS) is more successful.
5. Ansible instructs SSH to connect to a hostname equivalent to the the inventory name.
6. SSH hostname resolution fails.
6a. nova-conductor container's hostname and IP address is not in /etc/hosts (as openstack-ansible only configures /etc/hosts with inventoried hosts on *deployed* hosts, not *deployment* hosts)
6b. not in DNS (especially if the nova-conductor container was created shortly before-hand, ie a new deployment).
7. The nova-compute is marked as unreachable for the "Perform a cell_v2 discover" task because the delegated-to nova-conductor could not be reached by SSH using the nova-conductor's inventory name.