[network] wrong parsing of the bridge_mapping

[Petr Michalec]

I have checked the master branch and IMHO we are wrong in parsing bridge_mappings for openvswich.

Instead of that we pick the value from bridge_mapping_interface and try to split ":" however that value like 'eth0' is not supposed to contain any "bridge name" right? https://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/openvswitch.rb#L166

Proposed fix + scripted ip move:

unless ['nicira', 'plumgrid', 'bigswitch'].include?(main_plugin)
  unless node['openstack']['network']['openvswitch']['bridge_mapping_interface'].to_s.empty?
    ext_bridge_iface = node['openstack']['network']['openvswitch']['bridge_mapping_interface']
    ext_bridge_mappings = node['openstack']['network']['openvswitch']['bridge_mappings']
    # TODO, there may be more than one mapping specified
    ext_bridge_name, ext_bridge = ext_bridge_mappings.split(',')[0].split(':')

    file "/etc/neutron/move_ext_iface_addr_to_ext_bridge.sh" do
      content <<EOS
        iface_cidr=`ip addr show dev #{ext_bridge_iface} scope global |awk '/inet/ {print $2}'`

        # recreate brigde
        ovs-vsctl br-exists #{ext_bridge} || ovs-vsctl add-br #{ext_bridge} -- add-port #{ext_bridge} #{ext_bridge_iface}

        # MOVE IP ADDR
        ip addr flush #{ext_bridge_iface}
        ip addr add ${iface_cidr} dev #{ext_bridge}
        ip link set #{ext_bridge} up

        # in my case I somehow lost the orig interface IP and custom default route, so I do have to run at least to make the box accessible
        ip addr add ${iface_cidr} dev eth0

EOS
      owner "root"
      group "root"
      mode 00744
    end

    execute 'create data network bridge' do
      command '/etc/neutron/move_ext_iface_addr_to_ext_bridge.sh'
      action :run
      not_if "ovs-vsctl br-exists #{ext_bridge}"
      only_if "ip link show #{ext_bridge_iface}"
      notifies :restart, 'service[neutron-plugin-openvswitch-agent]', :delayed
    end

    # TODO, update os config with "up <path>" script to move IP on iface init.

  end
end

[John Kasperski (jckasper)]

The ['openstack']['network']['openvswitch']['bridge_mapping_interface'] is defined to be:

   # Create OVS data network bridge for the physical network and configure it
   # with the specified port. If nil or empty string is specified, the data
   # network bridge will not be created.
   # Format: <data network bridge name>:<external interface>
   #
   # Example: bridge_mapping_interface = br-eth1:eth1
   default['openstack']['network']['openvswitch']['bridge_mapping_interface'] = nil

Perhaps you are thinking about the L3 properties which were implemented as two separate properties.

   # Name of bridge used for external network traffic. This should be set to
   # empty value for the linux bridge
   default['openstack']['network']['l3']['external_network_bridge'] = 'br-ex'

   # Interface to use for external bridge.
   default['openstack']['network']['l3']['external_network_bridge_interface'] = 'eth1'

The ['openvswitch']['bridge_mapping_interface'] was defined similar to how the ['openvswitch']['bridge_mappings'] property is defined.

   # Comma-separated list of <physical_network>:<bridge> tuples
   # mapping physical network names to the agent's node-specific OVS
   # bridge names to be used for flat and VLAN networks. The length of
   # bridge names should be no more than 11. Each bridge must
   # exist, and should have a physical network interface configured as a
   # port. All physical networks listed in network_vlan_ranges on the
   # server should have mappings to appropriate bridges on each agent.
   #
   # Example: bridge_mappings = physnet1:br-eth1
   default['openstack']['network']['openvswitch']['bridge_mappings'] = nil

[John Kasperski (jckasper)]

A possible "simplification" might be to combine the openvswitch [bridge_mappings] and [bridge_mappings_interface] properties into a single entity. For example, instead of "Comma-separated list of <physical_network>:<bridge> tuples" it could be a "Comma-separated list of <physical_network>:<bridge>:<interface> triples".

The first 2 of this triple would be placed in the "bridge_mappings" field of ovs_neutron_plugin.ini. The last 2 fields would be used by the IP movement logic to create the necessary OVS bridge(s).

[Petr Michalec (epcim)]

Agree with John.

Keep it as simple as possible. BTW: Have a look on Ansible implementation in general context (it's more smooth - since python 2 python). We actually have a need to create resource providers that will call Python classes directly (and pass simple hash objects).

[Launchpad Janitor (janitor)]

[Expired for OpenStack + Chef because there has been no activity for 60 days.]