Bug 1734354

Summary: packstack install with vxlan/geneve tenant network fails due to dodgy parsing of facter -p
Product: [Community] RDO Reporter: Peter Dunning <pdunning>
Component: openstack-packstackAssignee: Martin Magr <mmagr>
Status: NEW --- QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: derekh, foliveira3, srevivo
Target Milestone: ---   
Target Release: trunk   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Peter Dunning 2019-07-30 10:37:09 UTC
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.

Comment 1 Fred Oliveira 2020-01-24 17:37:54 UTC
This is still present in the Train and master branches if either neutron-ovs-tunnel-if or neutron-ovn-tunnel-if is specified.

As the Peter describes above, the issue seems to be with the parsing of the `facter -p` output in prescript_000.py.   This should likely be recoded to use `puppet facts` as recommended by facter -p.