Bug 976380 - Packstack does not support provider external networks
Summary: Packstack does not support provider external networks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 3.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: async
: 3.0
Assignee: Terry Wilson
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-20 13:14 UTC by Rami Vaknin
Modified: 2019-09-10 14:10 UTC (History)
12 users (show)

Fixed In Version: openstack-packstack-2013.1.1-0.22.dev632.el6ost
Doc Type: Enhancement
Doc Text:
The CONFIG_QUANTUM_L3_EXT_BRIDGE configuration key now accepts a new value, "provider". Specifying this value instead of a bridge name will result in the L3 agent being configured to use external provider networks. Previously PackStack deployments did not support the use of external provider networks.
Clone Of:
Environment:
Last Closed: 2013-07-15 19:16:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 35507 0 None None None Never
OpenStack gerrit 36283 0 None None None Never
Red Hat Product Errata RHBA-2013:1058 0 normal SHIPPED_LIVE Red Hat OpenStack 3.0 bug fix advisory 2013-07-15 23:16:24 UTC

Description Rami Vaknin 2013-06-20 13:14:23 UTC
Version:
Grizzly on rhel6.4, puddle 2013-06-19.1

Description:
Due to issues with vlan splinters, we need to work with empty l3 external bridge, packstack's keyword for this configuration is CONFIG_QUANTUM_L3_EXT_BRIDGE, however, it has default value of "br-ex" and there is a failure when trying to enter an empty string using empty double quotes:

"ERROR : Failed handling answer file: Given value is not allowed: "

Comment 2 Terry Wilson 2013-07-03 16:32:55 UTC
Since the default for both packstack and the puppet-quantum module is for the CONFIG_QUANTUM_L3_EXT_BRIDGE/external_network_bridge setting is br-ex, we can't just allow an "empty" setting for that option. As a solution, I added the option CONFIG_QUANTUM_L3_EXT_BRIDGE=provider which will translate into a puppet manifest containing external_network_bridge => false. This should allow the use of a provider network.

In addition, I added the option CONFIG_QUANTUM_OVS_BRIDGE_IFACES to allow a mapping between an OVS bridge name and an interface on the the host. Using this option will allow packstack to add an interface to an OVS bridge. For example:

    CONFIG_QUANTUM_OVS_VLAN_RANGES=physnet1:1000:2000
    CONFIG_QUANTUM_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1
    CONFIG_QUANTUM_OVS_BRIDGE_IFACES=br-eth1:eth1

would set up a network labeled 'physnet1' with an OVS bridge named br-eth1, and add the eth1 interface to the br-eth1 OVS bridge.

Comment 5 Ofer Blaut 2013-07-09 08:42:59 UTC
There are two issues (openstack-packstack-2013.1.1-0.21.dev632.el6ost.noarch
, openstack-quantum-2013.1.2-4.el6ost.noarch )

1. I have configure answer file 

CONFIG_QUANTUM_L3_EXT_BRIDGE=provider

After installation content of /etc/quantum/l3_agent.ini is:

# empty value for the linuxbridge plugin.
# external_network_bridge = br-ex
external_network_bridge = False

But L3 agent alert 

2013-07-09 11:22:41    ERROR [quantum.agent.l3_agent] The external network bridge 'False' does not exist
2013-07-09 11:22:48    ERROR [quantum.agent.l3_agent] The external network bridge 'False' does not exist
2013-07-09 11:22:53    ERROR [quantum.agent.l3_agent] The external network bridge 'False' does not exist


2. About CONFIG_QUANTUM_OVS_BRIDGE_IFACES
 
It seems it only effect  the host include quantum DHCP/L3 , but not the compute nodes , which in my case are different hosts than the quantum DHCP

Comment 6 Ofer Blaut 2013-07-09 08:45:42 UTC
There is nothing in the answer file enplaning the provider option , we need to add a comment for it as well

Comment 7 Ofer Blaut 2013-07-09 08:54:58 UTC
Hi Terry

I think once packstack is configure to CONFIG_QUANTUM_L3_EXT_BRIDGE=provider,

external_network_bridge = should be empty  , as quantum support it 


Ofer

Comment 8 Terry Wilson 2013-07-09 13:58:04 UTC
external_network_bridge should be empty in the config file, but I thought that it needed to be an unquoted false in the manifest since there was a default value. It worked when I tested it. I'll revisit it this morning to verify. I see the problem with IFACES and that is a quick fix. Thanks.

Comment 9 Terry Wilson 2013-07-09 15:55:08 UTC
Ofer, yes. it external_network_bridge should be empty *in the config file*. It is a little trickier in the puppet manifest due to some possible bugs with how puppet's ini_setting handles empty values.

I'm trying to find a solution that doesn't involve modifying the upstream puppet module. What really needs to happen is that if the external_network_bridge in the puppet manifest is undef, then we check for that and do an ensure => absent on the setting in the l3_agent_cofnig call. I was hoping that just setting it to undef in the manifest would work (or an empty string) but neither works perfectly.

Comment 10 Terry Wilson 2013-07-09 16:12:14 UTC
Actually, we can't do the ensure => absent thing because the default *in the neutron code* is br-ex. So for now we may have to live with the bug that happens when you do:

class { 'quantum::agents::l3':
  use_namespaces          => 'True',
  interface_driver        => 'quantum.agent.linux.interface.OVSInterfaceDriver',
  external_network_bridge => '',
}

which is that on successive runs of packstack, multiple external_network_bridge settings will be added. The puppet module essentially completely ignores settings with empty values. So if the answer file is changed to have L3_EXT_NETWORK_BRIDGE=br-ex from =provider, then there will be lines:

external_network_bridge=
external_network_bridge=br-ex

and if the answer file is changed again to L3_EXT_NETWORK_BRIDGE=br-something then:

external_network_bridge=
external_network_bridge=br-something

as the ini_setting stuff works fine when there is a non-empty value.

I suggest that for now we deal with fixing the manifest to contain the empty string with the known issue of multiple packstack runs causing the multiple lines when empty values exist. Then, open a bug to fix that separately in the upstream puppet code.

Comment 13 Nir Magnezi 2013-07-11 07:38:26 UTC
(In reply to Terry Wilson from comment #10)
> Actually, we can't do the ensure => absent thing because the default *in the
> neutron code* is br-ex. So for now we may have to live with the bug that
> happens when you do:
> 
> class { 'quantum::agents::l3':
>   use_namespaces          => 'True',
>   interface_driver        =>
> 'quantum.agent.linux.interface.OVSInterfaceDriver',
>   external_network_bridge => '',
> }
> 
> which is that on successive runs of packstack, multiple
> external_network_bridge settings will be added. The puppet module
> essentially completely ignores settings with empty values. So if the answer
> file is changed to have L3_EXT_NETWORK_BRIDGE=br-ex from =provider, then
> there will be lines:
> 
> <snip>

Terry, 

Why can't it work the same as the packstack answer file CONFIG_SSL_CERT attribute?

This attribute accepts empty value as default for generating a self signed certificate.

answer file relevant lines:
# PEM encoded certificate to be used for ssl on the https server,
# leave blank if one should be generated, this certificate should not
# require a passphrase
CONFIG_SSL_CERT=

Comment 15 Alan Pevec 2013-07-11 18:09:09 UTC
Terry, there's needinfo from you in comment 13

Comment 16 Terry Wilson 2013-07-11 18:40:27 UTC
Nir: We can't use that method because there is an existing default of br-ex. So you if you tried to input an empty value, it would be selecting 'br-ex' instead of setting it to an empty string, which is what we need.

Comment 17 Ofer Blaut 2013-07-12 04:48:21 UTC
Tested on openstack-packstack-2013.1.1-0.23.dev642.el6ost.noarch

# Type of network to allocate for tenant networks
CONFIG_QUANTUM_OVS_TENANT_NETWORK_TYPE=vlan

# A comma separated list of VLAN ranges for the Quantum openvswitch
# plugin
CONFIG_QUANTUM_OVS_VLAN_RANGES=inter-vlan:195:203

# A comma separated list of bridge mappings for the Quantum
# openvswitch plugin
CONFIG_QUANTUM_OVS_BRIDGE_MAPPINGS=inter-vlan:br-eth3


# The name of the bridge that the Quantum L3 agent will use for
# external traffic, or 'provider' if using provider networks
CONFIG_QUANTUM_L3_EXT_BRIDGE=provider


Content of /etc/quantum/l3_agent.ini is 

# Name of bridge used for external network traffic. This should be set to
# empty value for the linuxbridge plugin.
# external_network_bridge = br-ex
external_network_bridge =

Comment 19 errata-xmlrpc 2013-07-15 19:16:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1058.html


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