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
To avoid it being created multiple times for multinode setup.
Note: This reverts "Enable neutron to work in a multi node setup"
(commit 88f8558d874072536e7660a233f24207a7089651) partly and fixes
the issue differently.
The configuration in question uses the new lib/neutron. (not neutron-legacy)
In that case, calling create_neutron_initial_network from stack.sh directly
is a wrong way, as create_neutron_initial_network is sourced by
neutron-legacy. The new neutron code should not rely on the legacy one.
Closes-Bug: #1613069
Change-Id: I868afeb065d80d8ccd57630b90658e330ab94251
Q_ variables belong to neutron-legacy.
These are True by default in neutron.
Remove them in favor of post-config meta section.
Change-Id: If691a79b09003f85a07c9f33e0379a2b21e48141
With the plan [1] to stop enabling it by Neutron iptables firewall
driver itself, deployment tools should catch up and enable the firewall
themselves.
This is needed for distributions that decided to disable the kernel
firewall by default (upstream kernel has it enabled). This is also
needed for distributions that ship newer kernels but don't load the
br_netfilter module before starting nova-network or Neutron iptables
firewall driver. In the latter case, firewall may not work, depending on
the order of operations executed by the driver.
To isolate devstack setups from the difference in distribution
kernel configuration and version, the following steps are done:
- we load bridge kernel module, and br_netfilter if present, to get
access to sysctl knobs controlling the firewall;
- once knobs are available, we unconditionally set them to 1, to make
sure the firewall is in effect.
More details at:
http://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf
[1] I9137ea017624ac92a05f73863b77f9ee4681bbe7
Change-Id: Id6bfd9595f0772a63d1096ef83ebbb6cd630fafd
Related-Bug: #1622914
Stud is now abandonware (see https://github.com/bumptech/stud) and is
not packaged in xenial. Lets use Apache for SSL termination since its
there already.
Change-Id: Ifcba410f5969521e8b3d30f02795541c1661f83a
The flag ENABLE_DEBUG_LOG_LEVEL indicates if this should be
set or not.
This will now be supported in Neutron.
Change-Id: I3afe0546b379873247fee1ef9f4cc2708a7b5713
On the controller node where devstack is being run should create
the neutron network. The compute node should not.
The the case that we want to run a multi-node neutron setup we need
to configure the following (in the case that a plugin does not
have any agents running on the compute node):
ENABLED_SERVICES=n-cpu,neutron
In addition to this the code did not enable decomposed plugins to
configure their nova configurations if necessary.
This patch ensure that the multi-node support works.
Change-Id: I8e80edd453a1106ca666d6c531b2433be631bce4
Closes-bug: #1613069
When running a default devstack environment, having guests that
actually can resolve DNS, so that they can do package updates from
well known hosts. This addresses a gap between nova-net and neutron
behavior in devstack.
Change-Id: I42fdc2716affd933e9158f1ef7ecb20bc664ef21
The common code for metering calls _neutron_service_plugin_class_add,
which despite the description only just appends a service plugin to
$Q_SERVICE_PLUGIN_CLASSES - it doesn't actually write it into a
configuration file.
So for now, read out the configuration, and append metering to it, then
write it back out.
Change-Id: Ice96cca8b43dcd54f2aa81461000a4597db8260d
When running a compute node that only runs n-cpu and neutron-agent,
there are still configuration items that are needed by the agent that
reside in $NEUTRON_CONF - such as the rabbit rpc information.
Change-Id: Ib7f5dde3afb0c19dc88f351c99bc669217952a14
The commit message of 2a242519f71e86416e78541826cac2b54fcd04a5 indicated
that neutron-metadata-agent was the correct name for the metadata
proxy, but parts of the code were not consistent.
Change-Id: I52f08266a169aeb9005c0f84296fc814d05b90d4
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
Preparing to refactor lib/neutron to support Neutron as the default
network config. lib/neutron will be renamed internally and refined
to support a couple of specific configurations.
Change-Id: I0d3773d14c4c636a4b915734784e7241f4d15474
This patch is causing blocking failures in some 3rd party CIs.
The issue can be tracked to the fact that the PUBLIC_INTERFACE
interface might have no address assigned.
This reverts commit 93b2100c983e1c271a8d51aa7f4755a6445be6a8.
Partial-Bug: #1436607
Change-Id: I0943aa542b911fbcebb100543e0adbb38159b233
When running Neutron on a single node that only has a single interface,
the following operations are required:
* Remove the IP address from the physical interface
* Add the interface to the OVS physical bridge
* Add the IP address from the physical interface to the OVS bridge
* Update the routing table
The reverse is done on cleanup.
In order run Neutron on a single interface, the $PUBLIC_INTERFACE and
$OVS_PHYSICAL_BRIDGE variables must be set.
Co-Authored-By: Brian Haley <brian.haley@hp.com>
Change-Id: Ie35cb537bb670c4773598b8db29877fb8a12ff50
This eliminated a number of sudo calls by doing the copy/chown/chmod in
a single step and sets a common pattern.
Change-Id: I9c8f48854d5bc443cc187df0948c28b82c4d2838
iniset_rpc_backend should know what section it needs to set the
config options in better than the callers. The config options
have actually been moved to different sections and the options
in the DEFAULT section are deprecated.
Change-Id: I0e07fe03c7812ef8df49e126bf71c57588635639
Use authentication plugins for neutron -> nova communications and
default to using the password plugin, which defaults to using the
v3 Identity API.
Neutron config change: 13427a40768f1a4646520c6b7e3e8c988ce6e18c
Change-Id: If152b97f940286ed08767225b13dedf6ef8c2342
The StrongSwan driver under development for kilo-3 will replace the
default reference OpenSwan driver.
In the interim though, we need to be able to run functional tests
for both drivers. This change is intending to do the additional
steps that are needed to set up for Strongswan, so that when a
functional test has IPSEC_PACKAGE=strongswan, everything will be
correct.
The intent here is to explicitly set the device driver class in
vpn_agent.ini, so that this will work for when OpenSwan is the
default (currently), when no drivers are specified, and will work
for when StrongSwan is made the default in the code.
For Ubuntu, AppArmor is disabled for charon and stroke.
Note: Both OpenSwan and StrongSwan cannot be installed on the
host at the same time.
Change-Id: Ib8467e24633230d6643d812068e4ed6ffb33f104
Partial-Bug: 1424757
Devstack support for LBaaS is being migrated to an external
plugin in the neutron-lbaas repository. The only LBaaS-
specific code that remains in devstack is a hook to support
existing configs that enable q-lbaas. In that case, load
the external plugin if necessary.
Change-Id: I592f64407ccf1e722b8d9788917879d0236acf0b
Depends-On: I64a94aeeabe6357b5ea7796e34c9306c55c9ae67
The $PHYSICAL_NETWORK in the error message should be
$PRIVATE_NETWORK_NAME, because the command just before this error
message refers to $PRIVATE_NETWORK_NAME.
Change-Id: I9a648f8bd0e61abde8e93bc08282c14b35ec06bd
The code for creating service users is almost exactly the same. Abstract
this into a function that can be reused and standardized.
Change-Id: I3a4edbff0a928da7ef9b0097a5a8d508fdfab7ff
