This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1006534 - Packstack ignores neutron physical network configuration if CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre
Packstack ignores neutron physical network configuration if CONFIG_NEUTRON_OV...
Status: CLOSED CURRENTRELEASE
Product: RDO
Classification: Community
Component: openstack-packstack (Show other bugs)
unspecified
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Martin Magr
Ofer Blaut
: Reopened
Depends On:
Blocks: 1040649
  Show dependency treegraph
 
Reported: 2013-09-10 14:58 EDT by Bob Kukura
Modified: 2016-03-30 18:59 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-30 18:59:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Config file (6.13 KB, text/plain)
2013-10-29 10:52 EDT, Rushil Chugh
no flags Details

  None (edit)
Description Bob Kukura 2013-09-10 14:58:29 EDT
Description of problem:

My answer file includes the following:

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre
CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-eth1:eth1
CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:1000

My intent is to use GRE tunnels for tenant networks, but use a VLAN on eth1 for my external network.

The installation completed, and configuration for the tenant GRE tunnels looks correct, but the configuration for the physical network was ignored.


Version-Release number of selected component (if applicable):

openstack-packstack.noarch       2013.2.1-0.9.dev756.el6       @openstack-havana


How reproducible:

every time


Steps to Reproduce:
1. Run packstack with options above
2. Examine configuration for server and agents
3. Try to create a provider network using physnet1

Actual results:

On the server node, /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini does not contain network_vlan_ranges.

On the nodes where neutron-openvswitch-agent runs, /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini does not contain bridge_mappings, and br-eth1 has not been created.

Provider external network cannot be created because physnet1 is not known.


Expected results:

On the server node, /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini should contain: "network_vlan_ranges = physnet1".

On the nodes where neutron-openvswitch-agent runs, /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini should contain "bridge_mappings=physnet1:br-eth1", and the br-eth1 OVS bridge should be created with eth1 added as a port.


Additional info:

N/A
Comment 1 Gilles Dubreuil 2013-09-11 05:59:19 EDT
Erratum, this was due to guestfs.py being copied accross from havana2.

Therefore closing it.
Comment 2 Bob Kukura 2013-09-11 11:20:26 EDT
I don't think this was the bug Gilles intended to close.
Comment 3 Gilles Dubreuil 2013-09-11 20:22:55 EDT
Sorry, I effectively closed the wrong one, too many windows opened.
Comment 4 Rushil Chugh 2013-10-17 20:55:31 EDT
Hi Bob
So I was basically trying to reproduce what you have explained above. 
So for configuring the above, are you using just a single server and a single client? Or can I use multiple clients for the same? 
I had another query and this might be trivial. Do I need to run the same script that you have given above on the server and the client?
Thanks
Rushil
Comment 5 Bob Kukura 2013-10-23 14:22:08 EDT
My setup used separate controller (i.e. server) and compute nodes, but that should not be necessary to reproduce the bug. I'd suggest starting with a single-node packstack install using an answer file with the settings above. The neutron-server and neutron-openvswitch-agent will both be configured to run on that node, and I suspect the /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini file will not contain the expected network_vlan_ranges value.
Comment 6 Rushil Chugh 2013-10-29 10:52:13 EDT
Bob
My ovs_neutron_plugin.ini file does contain the following output:
CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1
Is this what you were looking for? I have attached my ovs_neutron_plugin.ini file with this bug for reference.
Regards
RUshil


(In reply to Bob Kukura from comment #5)
> My setup used separate controller (i.e. server) and compute nodes, but that
> should not be necessary to reproduce the bug. I'd suggest starting with a
> single-node packstack install using an answer file with the settings above.
> The neutron-server and neutron-openvswitch-agent will both be configured to
> run on that node, and I suspect the
> /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini file will not
> contain the expected network_vlan_ranges value.
Comment 7 Rushil Chugh 2013-10-29 10:52:59 EDT
Created attachment 817109 [details]
Config file
Comment 8 Bob Kukura 2013-10-29 12:00:05 EDT
Your attached ovs_neutron_plugin.ini file generated by packstack does not contain the following expected items:

network_vlan_ranges = physnet1
bridge_mappings=physnet1:br-eth1


These should be present when the packstack answer file contains:

CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1


Regardless of whether the answer file contains:

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre

or


CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=local

or 


CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=vlan
Comment 11 Mike Orazi 2014-03-31 12:53:23 EDT
Fixing bug ownership.
Comment 12 jliberma@redhat.com 2014-04-08 13:44:32 EDT
This is still an issue.

Snippet from my answer file:
CONFIG_NEUTRON_L3_HOSTS=10.16.137.106
CONFIG_NEUTRON_L3_EXT_BRIDGE=provider
CONFIG_NEUTRON_L2_PLUGIN=openvswitch
CONFIG_NEUTRON_DHCP_HOSTS=10.16.137.106
CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre
CONFIG_NEUTRON_OVS_VLAN_RANGES=physext
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physext:br-em2
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-em2:em2
CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:1000
CONFIG_NEUTRON_OVS_TUNNEL_IF=p3p1

I had to execute the following commands to have a functional external provider network with br-em2 for GRE traffic:

# Neutron server
ssh rhos1 "openstack-config --set /etc/neutron/plugin.ini OVS network_vlan_ranges physext"
ssh rhos1 "openstack-config --set /etc/neutron/plugin.ini OVS bridge_mappings physext:br-em2"

# L3 server, network node
ssh rhos6 "openstack-config --set /etc/neutron/plugin.ini OVS network_vlan_ranges physext"
ssh rhos6 "openstack-config --set /etc/neutron/plugin.ini OVS bridge_mappings physext:br-em2"
ssh rhos6 "ovs-vsctl add-br br-em2"
ssh rhos6 "ovs-vsctl add-port br-em2 em2"

# L2 servers, compute nodes
for i in rhos4 rhos5 
do
        ssh $i "openstack-config --set /etc/neutron/plugin.ini OVS network_vlan_ranges physext"
        ssh $i "openstack-config --set /etc/neutron/plugin.ini OVS bridge_mappings physext:br-em2"
        ssh $i "ovs-vsctl add-br br-em2"
        ssh $i "ovs-vsctl add-port br-em2 em2"
done

# restart all openstack and neutron services
for i in 7 6 5 4 1
do
        ssh rhos$i "for svs in \$(chkconfig | awk '(/openstack/ || /neutron/) && /:on/ {print \$1}'); do service \$svs restart; done"
done

The important step seemed to be adding the physical interface to the bridge. My neutron.conf and plugin.ini had the appropriate entries but ovs-vsctl list-ports br-em2 did not have em2 interface:

[root@rhos6 ~]# ovs-vsctl list-ports br-em2
em2
phy-br-em2

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