Cleaning and recreating network resources leads to conflicting o-hm0 interface
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Octavia Charm |
New
|
Undecided
|
Unassigned |
Bug Description
After using configure-resources to create the lb-mgmt network resources with ipv6, I wanted to change the network to ipv4 so I deleted the security groups, the subnet, network, and router and ran a script to manually create the ipv4 resources. The script is irrelevant as I was able to recreate the scenario by re-running the configure-resources action.
I believe the relevant action is that in order to delete the lbm-mgmt-net, I had to delete the health manager ports (such as octavia-
After re-creating the lb-mgmt network resources I saw that the o-hm0 interface had a different mac-address in the output of these two commands on the octavia units:
sudo ovs-vsctl list interface o-hm0
ip link show o-hm0
And I resolved this by running (on the octavia units):
sudo ovs-vsctl del-port o-hm0
And then running a charm hook with juju:
juju run -a octavia hooks/config-
It seems like the charm should query neutron to see if the port exists, and if not, delete the o-hm0 interface from ovs prior to creating the port in neutron.
The deployment where I saw this behavior is focal-ussuri with the following charm versions:
octavia 6.2.1 active 3 octavia charmstore stable 39 ubuntu Unit is ready
octavia-ovn-chassis 20.03.2 active 3 ovn-chassis charmstore stable 21 ubuntu Unit is ready