Bug 1734354 - packstack install with vxlan/geneve tenant network fails due to dodgy parsing of facter -p
Summary: packstack install with vxlan/geneve tenant network fails due to dodgy parsing...
Alias: None
Product: RDO
Classification: Community
Component: openstack-packstack
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: trunk
Assignee: Alfredo Moralejo
QA Contact: Shai Revivo
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-30 10:37 UTC by Peter Dunning
Modified: 2020-09-24 11:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 754073 0 None NEW Use netifaces instead of facter to find ip address 2020-09-24 11:50:02 UTC

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:

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:

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= --os-network-hosts= --os-compute-hosts=,
4. packstack --answer-file /root/answers.txt -d

Actual results:
Install works

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

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.

Note You need to log in before you can comment on or make changes to this bug.