Q_AGENT_EXTRA_AGENT_OPTS is deprecated now and stack.sh displays
the warning that it will be removed early in "K" cycle.
Neutron ML2 devstack uses Q_AGENT_EXTRA_AGENT_OPTS to pass tunnel
configurations to Neutron plugin agents.
This commit removes the usage of Q_AGENT_EXTRA_AGENT_OPTS and
configures these config options directly.
Change-Id: I7fc1613ff78c0a8b1e80cc041b06f5d4680c34f2
Closes-Bug: #1354670
The current code sets tunnel types for the neutron agent
even when the network type is 'vlan'. This results in the
agent not starting because 'vlan' is not a valid tunnel type.
This patch changes it so tunnel_types is not populated when
vlans are used.
This bug just now surfaced because of commit
8feaf6c9516094df58df84479d73779e87a79264 requiring Q_ML2_TENANT_NETWORK_TYPE
to be set to avoid being set to the 'local' type.
Change-Id: If2bc57b36dad2bfb34df573581acce176604812e
ovs vxlan become supported on most distribution and provides
isolated `multi tenant` networking without special `vlan` aware switch.
In single node deployment you will just see the br-tun ovs bridge
created.
In multi-node setup you might need to adjust the MTU settings.
If your physical switch supports >=1550 MTU size
probably you will not see any issue.
If your guest image honors the MTU size offered via dhcp,
you can adjust your dnsmask settings with the correct (likely 1450 byte)
MTU size.
cirros (udhcp) does not honors these setting, you might need to
set lower MTU size on br-ex and/or adjust network_device_mtu option
in your local.conf.
The default changed, because it will be used with the multi-node neutron
jobs.
If you want the original behavior for whatever reason add these to your
`local.conf`:
ENABLE_TENANT_TUNNELS=False
Q_ML2_TENANT_NETWORK_TYPE=local
Change-Id: Id33ff0eca44905b3996618f1035ad984a6819b5b
Now that the Neutron database is healed we no longer need a
plugin-specific name for it.
Related Blueprint: db-migration-refactor
Change-Id: If25e77444f115817e5570bb447bde5b9c8d6e686
This patch introduces a new Neutron config option: Q_DVR_MODE.
The possible values are:
- legacy : No DVR functionality
- dvr_snat: Controller/single node DVR
- dvr : Compute node in multi-node DVR
When DVR is enabled the following configuration changes will be
in place:
- neutron.conf
- router_distributed=True
- l3_agent.ini
- agent_mode=$Q_DVR_MODE
- ovs_neutron_plugin.ini:
- enable_distributed_routing=True
- l2_population=True
- tunnel_types=vxlan
Supports-blueprint: neutron-ovs-dvr
Change-Id: I669e054a8489fe7ac7f5c00df6535349d477e8c4
The HOST_IP address is being used as IP address
for end-point tunnel configruation. A new variable is
needed to specify a different IP address for the tunnel
end-point that Neutron will use
Change-Id: Ic7fb4853df167e78bf882af6a712b903db754dc2
Closes-bug: #1340433
The files changed in this commit had incorrect bash syntax in that they were
assigning variables (=) instead of checking if they were equal (==). The
incorrect checks were preventing the configuration of VLANs with the Neutron
ML2 plugin.
Change-Id: I4b54bb5c69cc836c22900bd7a966197e9c616076
The various Neutron plugin files need to have unique variables for the
xtrace state as they are sometimes nested more than two levels deep
and MY_XTRACE is getting stomped. This gives each of the neutron_plugin
and neutron_thirdparty include files a unique XTRACE state variable.
I don't think this is a problem with any of the other plugin include
files (yet) so this just handles Neutron for now.
Change-Id: I7c272a48e7974edecaff5f431ff7443dd6622588
Check that function calls look like ^function foo {$ in bash8, and fix
all existing failures of that check. Add a note to HACKING.rst
Change-Id: Ic19eecb39e0b20273d1bcd551a42fe400d54e938
All other security group configs in Neutron are lower-case
and it should be consistent.
Change-Id: I683333c1e186446a69172446cca6d9b952673ed4
Closes-Bug: #1279862
When enabling neutron service (i.e. enable_service q-xxx), related code
unconditionally adds a necessary plugin class to Q_SERVICE_PLUGIN_CLASSES.
Which may cause duplication in Q_SERVICE_PLUGIN_CLASSES when
Q_SERVICE_PLUGIN_CLASSES is explicitly specified in localrc.
As a result, neutron server fails to start.
This patch introduces a utility function to add service class,
and check duplication.
Closes-Bug: #1261291
Change-Id: Id2880c7647babfccc3e8d9fc60dd93c4b3997ed9
Previously when running devstack with Neutron ML2 plugin,
an unnecessary file "ml2" is created in devstack directory.
It is because when the first argument is not defined the second
argument becomes the first one.
This change moves the first "options" argument of populate_ml2_config
to the last and checks the given options has a value before adding
them to a file.
Change-Id: I9ff40456798c42216d414d5f8d443e671ab7d497
Close-Bug: #1255853
ML2 uses a service plugin for L3. This patch to devstack
correctly sets this by setting or updating the variable
Q_SERVICE_PLUGIN_CLASSES, which makes ML2 compatible when
running with other service plugins (e.g. LBaaS and VPN).
Fixes bug 1231622
Change-Id: I0ce1f5a42bd052995135ffac1ee5ef382d69789e
The existing ML2 code overwrote extra options set in localrc with
defualt values in some cases. This fixes it so it no longer does
that and instead adds to rather than overrides those values.
Fixes bug 1222854
Change-Id: Iafdaad7d4253f1b61e8a214c50adaf7599a641f2
Since the addition of ML2 port-binding, the linuxbridge and openvswitch
drivers are required to be loaded when running with ML2. This small
patch adds their loading into ML2 into devstack.
Fixes bug 1220743
Change-Id: I97c5f4e0e4af59766e0084ed3b2dea2843cb33bf
The ML2 code in devstack was not correctly configuring the mechanism_drivers
when asked to do so. This corrects the typo in the variable assignment, and
also actually sets these in the plugin configuration file.
Fixes bug 1208557
Change-Id: I3746ca099f45d44dcf1cc2ca1c3726745b8e8a1d
This commit adds support to devstack to set ML2 options including
MechanismDrivers, TypeDrivers, and TypeDriver specific configuration for ML2
when running with devstack.
This also allows for simple configuration of VLAN, GRE, and VXLAN ML2 devstack
setups with the OVS agent as follows:
# VLAN configuration
Q_PLUGIN=ml2
ENABLE_TENANT_VLANS=True
# GRE tunnel configuration
Q_PLUGIN=ml2
ENABLE_TENANT_TUNNELS=True
# VXLAN tunnel configuration
Q_PLUGIN=ml2
Q_ML2_TENANT_NETWORK_TYPE=vxlan
Fixes bug 1200767
Change-Id: Ib16efac13440b5d50658a0e6be35bc735510a262