There is no longer a trace of these options anywhere in the
Neutron codebase. These can be safely removed.
Change-Id: Ibf00e158248e2a20248917c8cfc0011d30da6a82
This variable can be used to accommodate for underlying infrastructure
that does not provide full 1500-sized traffic, or maybe instead gives
access to Jumbo frames.
Change-Id: I38a80bac18673a30842a7b997d0669fed5aff976
Related-Bug: #1603268
Background for this work can be read on the mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094063.html
Usage of the new Neutron is by setting the following in
ENABLED_SERVICES:
* neutron-api
* neutron-l3
* neutron-agent
* neutron-dhcp
* neutron-metadata-agent
For now, the new neutron library supports just the ML2 plugin, with the
Open vSwitch and Linux Bridge agents supported. All other Neutron
plugins should be creating their own DevStack plugin if they wish for
DevStack to support them. Many of them already do.
Other notable changes compared to neutron-legacy:
* Rely on the Neutron defaults, and force Neutron to make
sane defaults instead of all kinds of knobs in DevStack.
* Default to rootwrap daemon support
* Use the security group driver by default
* interface_driver can now use NEUTRON_AGENT (linuxbridge, openvswitch), since
they are entrypoints in neutron's setup.cfg
* Use NEUTRON_AGENT variable to determine which agent to run
Works with NEUTRON_AGENT set to either "linuxbridge" or "openvswitch"
Default is openvswitch for the time being.
* Set ML2 configuration for VXLAN support
* Remove Xen hypervisor stuff - it should be a plugin
* Move L3 crud into separate service file:
There's a lot of L3 configuration that was in the main neutron file, but
a lot of it is self contained and can be moved into its own file.
The new l3 service file will contain all the previous L3 plumbing and
configuration that the OpenStack Gate expects, while also eventually
moving the whole l3 network creation step into a single hook that can be
overridden by plugins.
* Introduce a check for a function "neutron_plugin_create_initial_networks" which
will become the mechanism through which different topologies, and
networking plugins can create and wire the initial networks that are
created during a stack.sh run.
The new lib/neutron is considered experimental, and followup patches
will build upon this one. Existing users of lib/neutron-legacy should
remain unharmed.
Co-Authored-By: Hirofumi Ichihara <ichihara.hirofumi@lab.ntt.co.jp>
Co-Authored-By: Dean Troyer <dtroyer@gmail.com>
Change-Id: I31b6362c6d9992f425f2dedbbeff2568390a93da
Variables PUBLIC_INTERFACE_DEFAULT and GUEST_INTERFACE_DEFAULT
are only use to provide default value, deployment script should
not use such values directly
Closes-Bug: #1566768
Change-Id: Ib543b416df861086fa2edbe7df769b224d0b0add
After reviewing I5b1d49be8d9e3e331826e30182fba70f099b5e7f and
I161a157895b4ed0c9ea5a7a00302e30f4ad75ed3 - I have come to the
determination that this really should be in a DevStack plugin.
If both of the patches under review were to merge, we would be blessed
with at least the following variables:
OVS_NICS_FROM_BRIDGES
OVS_NIC_MAPPINGS
OVS_BRIDGE_MAPPINGS
OVS_PHYSICAL_BRIDGE
PHYSICAL_NETWORK
PUBLIC_PHYSICAL_NETWORK
Which really is not good. Let's just push this into a plugin, I don't
want to deal with it.
This reverts commit 3095ff51320291b3622cacc3bf2fb1043bff8d31.
Change-Id: I746022f5db93d3333101a014692fbdcd790a0004
1.4 was released in 2012. I think we can assume everyone is running
something newer.
http://openvswitch.org/releases/NEWS-1.4.0
Change-Id: I3cfe99d2647800ae3ffb32c9e6749d03224c2967
Allows the definition of the global variable OVS_BRIDGE_MAPPINGS (e.g.
in local.conf) to automatically trigger the creation of multiple OVS
bridges. For example:
OVS_BRIDGE_MAPPINGS=physnet1:br-br-enp0s20f1,physnet2:br-enp0s20f2
should automatically yield the creation of two bridges, respectively
associated to the two physical networks declared,
by simply running DevStack with the OVS agent enabled.
Documentation has also been added to doc/source/guides/neutron.rst.
Change-Id: I79dc0213c9d70ba628621c4c0f65481783590085
Closes-Bug: #1535835
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
The lack of a CI for XenAPI + Neutron has meant this support has been
broken over time. This is set of one-off fixes that are needed to
reintroduce support while we work towards getting a CI functional
Related-Bug: #1495423
Change-Id: Id41fdc77c155756bda9e2e9ac0446a49f06f0603
interface_driver configuration was updated to use stevedore aliases.
This patch is to change devstack scripts to now use the aliases
instead of the previous class imports.
Closes-Bug: #1504536
Change-Id: Ic56bfcc1f9da05a999e6fd328e4dd6617e9470ff
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
If OVS_DATAPATH_TYPE is configured it should be visible in ML2 config
Changing OVS_DATAPATH_TYPE default value to 'system' from ''
Closes-Bug: 1499029
Change-Id: I88e7d2554e8a1d6dcfea71fc1fb8e9fb2491d8b7
This change extends devstack to configure the br-ex,
br-<phy> and Xenserver's br-$GUEST_INTERFACE_DEFAULT
datapaths when OVS_DATAPATH_TYPE is set.
Change-Id: I71e590de86e7526e8423140463752d6b3ad14214
Closes-Bug: #1416444
These have been emitting deprecated warnings for over a full release cycle:
Q_AGENT_EXTRA_AGENT_OPTS, Q_AGENT_EXTRA_SRV_OPTS, CINDER_MULTI_LVM_BACKEND
Change-Id: I3aa5cabd6ce3a0072cba08bbca1ad23d4a831219
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
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
A typo has been introduced during a previous refactor, leaving us with
two neutron config files, one with domu and one with domU extension.
This fix corrects the mistake, thus always the .domU file is used.
Change-Id: Iffb6e2f70915f50ee590c375494c6f642412b543
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
Just like the beginning of every other release, remove the deprecated
config option aliases that were marked as deprecated in Icehouse.
Nova patch - https://review.openstack.org/#/c/88456/
Change-Id: Idd051c516002030e8e191c7b8d31f1ff408e1c7d
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