As part of the Victoria PTG the Neutron team entertained the idea of
having the OVN driver as the default backend in DevStack (this hasn't
yet being decided by the community, this will be discussed within this
cycle).
For this to happen, we also would need to move the module that configures
OVN to the DevStack repository. This is what this patch is doing.
Note that we are updating the lib/neutron-legacy module instead of
lib/neutron in this patch, this is because as part of the PTG the
Neutron team has decided to un-deprecate the neutron-legacy module since
the "new" lib/neutron module is broken and nobody is current working on
it (also all services uses neutron-legacy).
Also, the ovsdbapp has been added to the ALL_LIBS list because a gate
job in the ovsdbapp project repository relies on installing the library
from source instead of pip to run.
Depends-On: https://review.opendev.org/#/c/740663/
Change-Id: Ib4194329474e8d68a90886d2a04f027eecd741df
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch enables ARP Responder with DVR routers along with
l2pop in devstack.
Related-Bug: #1774459
Change-Id: I82f628c32f6e38c2419b6ffe90d9f9adf96777b1
Currently if PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK are
same then duplicate entry is created in ml2_conf.ini like below:
flat_networks = public,public,
With this patch, if PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK
are same then add only PHYSICAL_NETWORK to flat_networks in
ml2_conf.ini
Change-Id: Iae4d1ee3882f6d96b4e4abd52ecc673a620563b5
Closes-Bug: #1654148
Similar to 30ab23cd9b103470a7d89c4c88bccba789884c36, fix the
plugin name to avoid warnings like:
WARNING stevedore.named [-] Could not load neutron.plugins.ml2.plugin.Ml2Plugin
Change-Id: Ibb45f1305816b255ba2419ba662d9e29eff68f58
Sets the port_security feature flag in tempest.conf
if the port_security extension is enabled, which it's not
by default in neutron but is set by default in devstack.
This adds global variable for setting the port_security
extension in ml2.conf and in tempest.conf so we only have
to set this in one place.
Depends-On: I1efd5c838aa0d73cc6e8864e3041eea25850198d
Change-Id: I6334b200e42edd785f74cfb41520627393039619
Related-Bug: #1624082
===Set bridge_mappings for linux bridge===
The external network physnet needs a bridge_mapping to the public
bridge when the L2 agent is responsible for wiring.
===Add PUBLIC_PHYSICAL_NETWORK to flat_networks===
This network must be present in the ML2 flat_networks config if
flat_networks is specified.
===Set ext_gw_interface to PUBLIC_BRIDGE in provider net case===
ext_gw_interface must be a bridge in a bridge_mapping when
Q_USE_PROVIDERNET_FOR_PUBLIC is used.
Closes-Bug: #1605423
Change-Id: I95d63f8dfd21499c599d425678bf5327b599efcc
Add support for the "geneve" ML2 plugin type driver. The
networking-ovn ML2 mechanism driver uses geneve for its
project network type. Geneve is part of core neutron but
didn't have any DevStack configuration for it. This patch
set adds the necessary options. It also removes the default
for ML2 type drivers to rely on the neutron default and
consolidates the tunnel ranges default for gre, vxlan and
geneve by using TENANT_TUNNEL_RANGES.
Change-Id: Id75651dfe57a07045a6932a0369668f33c7eef09
Partial-Bug: #1588966
Due to the fix [1] of neutron-refactor, some flat network usages of devstack
installation start fale.
This fix enables ML2_L3_PLUGIN to be set to empty to solve the problem.
By default l3_router_plugin.L3RouterPlugin will be set to ML2_L3_PLUGIN,
and for neutron, in such of configuration, router (ASA some others) will be
set into supported_extension_aliases,
then devstack will create a router that we do not want in a flat network.
Before fix [1], we can disable q-l3 to aviod the issue.
But now we don't, and we need this fix to disable the whole L3 plugin.
[1] https://review.openstack.org/318145
Change-Id: I61a2142d5121e0af4cc6cdf50e6bceafaf791fb0
Neutron had a lot of work done during the Mitaka cycle to fix MTU
issues, so let's see if Neutron can stand on its own.
This commit reverts 06cfce37560243d22cd05b2c620be6702528a0b1
Neutron patches:
I6ffc8973c9b8f46cc19922ff04fdd2d23646b878
I4096a3e7704032fa4aa5c3aa8bcaec4e38d0d06d
I6a10c4dfc1f2198667f3d02528e2ca8020cb5bb8
Ic091fa78dfd133179c71cbc847bf955a06cb248a
Idf6221fee2c7da86123b330ad3c235ecc6868242
I6859ebdde1f7e3a8163b49d705620e522ada606a
Change-Id: Ie88c7ebb29adadde530217c95e2f38aacb119dc8
Setting path_mtu to reflect mtu for physical devices that handle traffic
issued from br-tun makes ml2 plugin to calculate mtu for tenant networks
properly, considering encapsulation headers. After that, calculated mtu
values can be propagated into instances (currently, only DHCP approach
is implemented; RA support for IPv6 subnets is under review).
This change allows to run tunnelled tenant networks in multinode when
underlying physical devices don't support jumbo frames.
Note: changing the default value in neutron would not be backwards
compatible, since it could slow down east-west tunnelled traffic in
clouds that run on jumbo-aware networks.
Change-Id: I8287677c7ad0f13fa9f5cb194f9372d04b78cb61
Related-Bug: #1527675
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
These files have acquired execute permissions that
are not strictly necessary because they are being
sourced, and not intended to be run separately.
Restore to 644
Change-Id: I0b8654123416a07521502b61610ca45c94494a07
Ml2 plugin always needs agent file even if the agent is out of tree.
This patch removes the restraint and ofagent_agent.
Change-Id: I12de58e13da1fd162ad8b632d895779ae7560c3c
Closes-Bug: #1477459
Configuration of local_ip is duplication in ml2 because there is
the configuration in both ml2 and openvswitch_agent.
It also should be set in each driver using openvswitch.
Change-Id: Ib0b874aed8db883d778426ed1ae01679fc0cc075
Neutron ML2 plugin introduces the first extension driver port_security, this
patch add it to be a default extension driver as a example. And also, if not
set it by default, networks like public/private which are created after the
neutron-db-manage's update, will not include the port-sec value.
Change-Id: I3035317c83d22804855517434bd8578719ce0436
Partially Implements: blueprint ml2-ovs-portsecurity
In an installation with VLAN tenant networks, devstack should
not configure the local_ip (which is applicable only when
tenant_tunnels are used). This is causing failures in Neutron
for an IPv6 only setup. This patch addresses this issue, but
configuring the local_ip only when TENANT_TUNNELS are enabled.
Related-Bug: #1447693
Change-Id: I0e2a2d8b6ce0ad87f6c0d318ac522dbab50d44ee
This commit fixes the issue that ml2 plugin
sets 'flat_networks' in ml2 configuration file as
empty. The value of 'flat_networks' need to be set
as the name of the physical network that was specified
in the localrc file (or it's default value).
Change-Id: Ib4c31f6576da57534b36aefebd1ca8cd397c6c1a
With gerrit 2.8, and the new change screen, this will trigger syntax
highlighting in gerrit. Thus making reviewing code a lot nicer.
Change-Id: Id238748417ffab53e02d59413dba66f61e724383
Add support to passing the flat_network configuration. User can
either passing the physical network name, or use the physical
network definition
Change-Id: Ie42679f207eb14620883778314f74abf378b5cbc
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