data-port and bridge-mapping config changes do not remove stale configurations from OVS database
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron Open vSwitch Charm |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
When performing a change to neutron-openvswitch to remove a bridge-mapping and data-port configuration (to backout from an improper OVS configuration) it was discovered that the charm does not remove the affected bridge. It would be handy if the charm either logged that the configuration change requires a database clearing and restart of OVS, or that the charm have an action to clean and re-build the OVS database on a given unit.
Steps to re-create:
1. setup neutron with GRE tunneling for overlay networking with eth0 having an L3 IP and eth1 being a provider trunk for vlan tagging with bindings "data: overlay-space"
2. set neutron-openvswitch data-port to 'br-data:eth0 br-provider:eth1' and bridge-mappings to 'physnet1:br-data physnet2:
Note that br-data now doesn't allow overlay traffic between nodes because the ovs bridge captures the overlay traffic before it makes it to eth0's L3 IP interface.
3. Backout the change to n-ovs such that data-port is 'br-provider:eth1' and bridge-mappings is 'physnet2:
4. witness that br-data bridge is still existant in OVS database with 'os-vsctl show'.
The confusion happened in thinking that when specifying bridge-mappings and data-port for provider networking that we'd have to manually configure the data overlay as we didn't understand exactly how bindings:data: worked, so we ended up adding br-data as we had in other sites where br-data was necessary because of using vlan overlay. Obviously, GRE doesn't require L2 bridge for overlay networking, but backing out of this change using juju config didn't update the OVS database to the prior state.
It was identified by one of our architects that changes to OVS charm require deleting the OVS database and restarting OVS/neutron-
sudo systemctl stop neutron-
sudo systemctl disable neutron-
sudo systemctl stop openvswitch-switch
sudo rm -rf /var/log/
sudo rm -rf /etc/openvswitc
sudo systemctl start openvswitch-switch
sudo systemctl enable neutron-
sudo systemctl start neutron-
sudo ovs-vsctl show
charmers release 17.02/Xenial/Mitaka
Inspection of previous configuration values should be possible so that automatic removal of devices from bridges could occur when configuration changes; its made slight tricky that in order to restore the previous state, we also need to understand whether an ifdown/ifup cycle needs to be performed on the nic.
In terms of manually recovering from this problem - you should have been able to use:
sudo ovs-vsctl del-port br-data eth0
which will remove eth0 as mapped to the br-data bridge back to the host OS.