Bug 1734354

Description of problem:
packstack fails to install openstack if the config dictates that vxlan or geneve should be used for the tenant network.
vxlan was my case, but in the following Q&A comments someone also tried geneve with the same results:
https://ask.openstack.org/en/question/122995/packstack-stein-cannot-detect-tunnel-interface/

Version-Release number of selected component (if applicable):
I'm using RDO-queens (openstack-packstack 12.0.0-2.el7).
This has also been seen on RDO-stein (see the Q&A link).
I can confirm by looking at the upstream repository for packstack that the relevant code has not been changed in years.

How reproducible:
100%

Steps to Reproduce:
1. Turn off firewall on both hosts
2. Setup appropriate repositories
3. packstack --allinone --gen-answer-file=/root/answers.txt --os-neutron-ml2-type-drivers=vxlan,flat --os-neutron-ml2-tenant-network-types=vxlan --os-neutron-ml2-mechanism-drivers=openvswitch --os-neutron-ovs-tunnel-if=p2p1 --os-controller-host=10.17.133.22 --os-network-hosts=10.17.133.22 --os-compute-hosts=10.17.133.22,10.17.133.24
4. packstack --answer-file /root/answers.txt -d

Actual results:
Install works

Expected results:
ERROR : "Couldn't detect ipaddress of interface p2p1 on node 10.17.133.24"


Additional info:
The error is raised at https://opendev.org/x/packstack/src/branch/stable/stein/packstack/plugins/neutron_350.py#L856
This is because of a key error looking up `config['HOST_DETAILS'][n_host][ifip]`. `n_host` is the IP of the host's control connection. ifip is of the form `'ipaddress_' + interface_name`.

These HOST_DETAILS come from https://opendev.org/x/packstack/src/branch/stable/stein/packstack/plugins/prescript_000.py#L1287
Here we find that the code attempts to parse the ruby hash output of `facter -p`. It does this by splitting on lines and then splitting at `'=>'` to get key/value pairs. This results in a rather bizarre looking results in the resulting dict. For example a large number of keys map to `'{'`.

In this case this causes problems because the `facter -p` output shows the interface IP addresses in nested sections per interface. This means that all the addresses are keyed on 'address' and so the last address overwrites all the previous ones. Nowhere in the output of `facter -p` is anything of the form `'ipaddress_' + interface_name`.

Incidentally the help for `facter` states that `-p` is deprecated and that `puppet facts` is to be preferred. `puppet facts` produces a JSON version of the output. In this case keys of the form `'ipaddress_' + interface_name` are used, and no home-rolled parser is required, due to json support being in the Python standard library.