FW: [networking-ovs-dpdk] Issue creating br-ex...

d.lake at surrey.ac.uk d.lake at surrey.ac.uk
Thu Dec 20 10:39:22 UTC 2018


"Have you tried running this by hand on the system and see what happens?

'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev'"


Yes - that creates the br-ex in ovs-vsctl on the second attempt but it does not create a bridge that ip link can act on. 

If I do an "ip link show br-ex" after the installation script has run, then I do not see a bridge at all on this system. 

There is no PUBLIC_BRIDGE because I'm not using one.  I am creating 4 DPDK NICS which are connected to the virtual machines.  Again, after many, many weeks of testing to arrive at a known-good configuration script, the assumption was that we could just push-the-button and roll-out re-installations at-will.

I will have 4 ovs bridge ports - br-dpdk1, br-dpdk2, br-dpdk3, br-dpdk4.   Each one will connect to one physical NIC.   Each will then be known in OpenStack as physnet1, physnet2, physnet3, physnet4.    This is how my existing system is setup and working using the Devstack installation system.


" Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by a recent change."

But I have no idea where to start looking!

I've also had to give up trying to install Queens as the installation script moans about oslo.concurrency and seems to be installing a version that it KNOWS is not compatible.  Again, this is something that worked perfectly on the installation I carried out in August.  Surely nothing can have changed in the basic installation in less than 6 months?   Even the basic command for cloning the networking_ovs_dpdk broke from the working local.conf because the -b stable/queens suffix failed.  In fact looking at the source site for that piece of code, there is no queens release on the site anymore.  I am now not sure if the version I have is compatible or not!

So I've had to clone devstack master which has now lead to the Cinder bug which I am now trying to patch around.

I'm hoping that we can get to a stable system by the time the centre shuts for Christmas tomorrow. Four days should have been more than enough given the working system which took three months to build!

Frustrated - but thank you for your help.

David


-----Original Message-----
From: Brian Haley <haleyb.dev at gmail.com> 
Sent: 20 December 2018 00:07
To: Lake, David (PG/R - Elec Electronic Eng) <d.lake at surrey.ac.uk>; openstack at lists.openstack.org
Subject: Re: FW: [networking-ovs-dpdk] Issue creating br-ex...

On 12/19/18 3:29 PM, d.lake at surrey.ac.uk wrote:
> Would appreciate some help here please.   Br-ex is not being added and 
> the mtu command causes the whole thing to not install.

Comments inline.

> *From:*Lake, David (PG/R - Elec Electronic Eng)
> *Sent:* 19 December 2018 15:22
> *To:* openstack-dev at lists.openstack.org
> *Subject:* [networking-ovs-dpdk] Issue creating br-ex...
> 
> Hello
> 
> Trying to re-run a Queens DPDK all-in-one using devstack which I built 
> in August and hitting issues.
> 
> The local.conf is identical between the two machines except I had to 
> take the "stable/queens" off the end of the "networking-ovs-dpdk" 
> plugin line as that no longer appears to work.
> 
> The installation seems to proceed until it gets to setting the ip mtu 
> on br-ex.
> 
> I'm not using br-ex.  I've declared OVS bridge mappings in the local.conf:
> 
> #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G 
> for the system.
> 
> OVS_NUM_HUGEPAGES=3072
> 
> #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G 
> for the system.
> 
> #OVS_NUM_HUGEPAGES=14336
> 
> OVS_DATAPATH_TYPE=netdev
> 
> OVS_LOG_DIR=/opt/stack/logs
> 
> #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2
> :br-dpdk4
> 
> OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2
> 
> #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-d
> pdk3,physnet4:br-dpdk4
> 
> OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2
> 
> [[post-config|$NOVA_CONF]]
> 
> [DEFAULT]
> 
> firewall_driver=nova.virt.firewall.NoopFirewallDriver
> 
> scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilt
> er,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilte
> r
> 
> [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
> 
> [OVS]
> 
> datapath_type=netdev
> 
> [ml2_type_flat]
> 
> #flat_networks=physnet1,physnet2,physnet3,physnet4
> 
> flat_networks=physnet1,physnet2
> 
> I cannot stress again how identical these systems are - same hardware, 
> same base OS install (CentOS 7.5).   I was (maybe erroneously!) 
> thinking that if I had it devstack working on one system, having an 
> identical system would be a piece of cake to install.
> 
> This is the installation error:
> 
> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21  local
> bridge=br-ex
> 
> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22  local
> 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex'
> 
> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24  '[' 
> netdev '!=' system ']'
> 
> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25
> addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge 
> br-ex datapath_type=netdev'
> 
> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28  sudo
> ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex 
> datapath_type=netdev

Have you tried running this by hand on the system and see what happens?

'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev'

It works for me locally, creating br-ex.  Perhaps there is some delay on your system?  But I would expect the call wouldn't return successfully then.

Or perhaps I'm mis-understanding and you meant to set PUBLIC_BRIDGE in your local.conf as well?

Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by a recent change.

-Brian


> +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119
> set_mtu br-ex 1500
> 
> +functions:set_mtu:750                     local dev=br-ex
> 
> +functions:set_mtu:751                     local mtu=1500
> 
> +functions:set_mtu:752                     sudo ip link set mtu 1500 
> +dev
> br-ex
> 
> Cannot find device "br-ex"
> 
> +functions:set_mtu:1                       exit_trap
> 
> +./stack.sh:exit_trap:522                  local r=1
> 
> ++./stack.sh:exit_trap:523                  jobs -p
> 
> +./stack.sh:exit_trap:523                  jobs=
> 
> +./stack.sh:exit_trap:526                  [[ -n '' ]]
> 
> +./stack.sh:exit_trap:532                  '[' -f /tmp/tmp.Dzbqzlk2fs ']'
> 
> +./stack.sh:exit_trap:533                  rm /tmp/tmp.Dzbqzlk2fs
> 
> +./stack.sh:exit_trap:537                  kill_spinner
> 
> +./stack.sh:kill_spinner:432               '[' '!' -z '' ']'
> 
> +./stack.sh:exit_trap:539                  [[ 1 -ne 0 ]]
> 
> +./stack.sh:exit_trap:540                  echo 'Error on exit'
> 
> Error on exit
> 
> +./stack.sh:exit_trap:542                  type -p generate-subunit
> 
> +./stack.sh:exit_trap:543                  generate-subunit 1545230781
> 1747 fail
> 
> +./stack.sh:exit_trap:545                  [[ -z 
> +/opt/stack/logs/screen ]]
> 
> +./stack.sh:exit_trap:548                  
> /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen
> 
> Can someone explain what is going on here please?
> 
> Thanks
> 
> 
> David
> 




More information about the openstack-discuss mailing list