27 Commits

Author SHA1 Message Date
Jenkins
f1d8278356 Merge "Remove stale config l3|dhcp_agent_manager options" 2016-08-17 14:02:44 +00:00
Armando Migliaccio
14b12a74f6 Remove stale config l3|dhcp_agent_manager options
There is no longer a trace of these options anywhere in the
Neutron codebase. These can be safely removed.

Change-Id: Ibf00e158248e2a20248917c8cfc0011d30da6a82
2016-08-12 19:07:12 -07:00
Ihar Hrachyshka
7b5c7dce53 Introduce PUBLIC_BRIDGE_MTU variable to set br-ex MTU
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
2016-07-17 00:14:43 +02:00
Sean M. Collins
2a242519f7 Begin new lib/neutron
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
2016-05-09 14:26:08 -04:00
Huan Xie
2f5596e590 Use configured values instead of default value
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
2016-04-10 20:05:43 -07:00
Sean M. Collins
54d16f706a Revert "Automate OVS bridge creation for multiple mappings"
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
2016-03-15 15:24:53 -04:00
Sean M. Collins
d1ee4cfdf9 Remove check for OVS_VERSION < 1.4
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
2016-03-08 15:25:16 -05:00
Igor Duarte Cardoso
3095ff5132 Automate OVS bridge creation for multiple mappings
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
2016-02-02 18:54:08 +00:00
Ian Wienand
523f488036 Namespace XTRACE commands
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
2015-11-27 15:36:04 +11:00
Huan Xie
201e3c133e XenAPI:Fix problems to support xenserver+neutron
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
2015-11-12 05:54:55 +00:00
Martin Hickey
dca49de22f Use stevedore aliases for interface_driver configuration
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
2015-11-02 20:33:20 +00:00
Aaron Rosen
bd5e6b1659 Remove unnecessary execute permissions
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
2015-10-01 21:01:35 +00:00
Michal Ptacek
c1605550d9 Propagate OVS_DATAPATH_TYPE to ml2_conf.ini
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
2015-09-24 17:45:08 +01:00
Hirofumi Ichihara
d48d672a8d Add tunnel_bridge configuration for openvswitch agent
Change-Id: I0235aa05cf86b3ed9d9620dda3f16b69ced077e3
2015-07-04 22:58:44 +09:00
Waldemar Znoinski
d4c89289f9 Set datapath to $OVS_DATAPATH_TYPE for bridges
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
2015-05-07 19:01:40 +01:00
Dean Troyer
311f487644 Remove deprecated vars
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
2015-02-11 10:56:47 -06:00
Sean Dague
e263c82e48 add shebang lines to all lib files
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
2014-12-10 11:28:05 -05:00
YAMAMOTO Takashi
d16197b689 Stop setting deprecated OVS.enable_tunneling option
The option has been deprecated in IceHouse and now being removed.

Related-Bug: #1195374
Change-Id: I38d962551173892144c369df71e0524b43e1fc89
2014-10-29 02:27:55 +00:00
Jenkins
3224f602f9 Merge "XenApi: Fix domu typo in neutron setup" 2014-08-23 10:54:12 +00:00
Akihiro Motoki
2307f9de75 Avoid using deprecated Q_AGENT_EXTRA_AGENT_OPTS in ML2 setup
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
2014-08-14 08:11:56 +09:00
Mate Lakat
1a247e8393 XenApi: Fix domu typo in neutron setup
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
2014-08-05 14:39:10 +01:00
Edgar Magana
6f335b9a4b Add a Tunnel end-point variable for Neutron configuration
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
2014-07-10 15:49:44 -07:00
Kyle Mestery
bd0855056b Fix incorrect comparisions
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
2014-05-08 10:29:34 +00:00
Gary Kotton
51c681d605 Add support for deprecated configuration vars in Juno
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
2014-04-26 01:45:27 -07:00
Dean Troyer
e3a9160c0d Fix Neutron plugin XTRACE handling
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
2014-03-28 12:40:59 -05:00
Ian Wienand
aee18c749b Enforce function declaration format in bash8
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
2014-02-28 07:59:03 +11:00
Mark McClain
b05c876994 update for name change to Neutron
Note: Nova and Horizon are not updated until those projects have
migrated.

Change-Id: I256ef20e7caadd9c96e6dd908c5d8b69ca5c4aeb
2013-07-07 00:15:11 -04:00