For change 739139 [1] PS 12, the
neutron-tempest-plugin-scenario-linuxbridge died in devstack with
"/opt/stack/devstack/functions-common:237 Failure retrieving default
route device", which comes from
"/opt/stack/devstack/lib/neutron-legacy:237:die_if_not_set".
Looking at the worlddump.txt for that job [2] I see that there is a
default ipv6 route; the vm was not configured with ipv4 networking.
ip route
--------
ip -6 route
-----------
::1 dev lo proto kernel metric 256 pref medium
2607:ff68:100:54::/64 dev ens3 proto kernel metric 256 expires 86380sec pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via fe80::f816:3eff:fe77:b05c dev ens3 proto ra metric 1024 expires 280sec hoplimit 64 pref medium
Looking at the devstack code that throws the error [3] it looks like
it only looks for a default route in the output of `ip route`, which
does not include ipv6 information. This change should look in both
the ipv4 and ipv6 route table. A similar check in the L3 setup code
is also updated.
[1] https://review.opendev.org/#/c/739139/
[2] https://d4eb7e3efe98cba79a4b-f4d168cdb20f40841821e4b213645c0f.ssl.cf2.rackcdn.com/739139/12/gate/neutron-tempest-plugin-scenario-linuxbridge/9a6b4f7/controller/logs/worlddump-latest.txt
[3] https://opendev.org/openstack/devstack/src/branch/master/lib/neutron-legacy#L236
Closes-Bug: #1902002
Change-Id: I839e8c222368df98fec308cf41248a9dd0a8c187
We need to enable accept_ra before we enable forwarding, otherwise
existing addresses and routes may get dropped until the next RA is
received, possibly causing connection errors in the meantime.
Change-Id: I1fdeede59547de896ed89222ecf121fd9e6b810d
It turns out that a host can have multiple valid default gateways,
something that's not common in ipv4.
This patches add supports for multiple default gateways in ipv6
environments.
Closes-Bug: #1786259
Change-Id: I30bf655f7160dd19c427ee79acdf145671a3e520
Signed-off-by: aojeagarcia <aojeagarcia@suse.com>
Allow users to auto-create a neutron non-flat providernet public network
and use it for external router interfaces. By default, keep the existing
flat network type behavior.
Change-Id: I64f71b0c9fcac97b9b84b7d30ee61659b2a690f1
The subnet-range parameter is only sent now if a valid value exists so
the command will not fail
Change-Id: I5296f5b59bc6d3d3db90a685a8678db9a156eece
Closes-Bug: #1718111
Add a missing --subnet-range argument when creating an ipv6 provider
network. Also changed SUBNET_V6_ID to IPV6_SUBNET_ID. And remove the
--ipv6-address-mode arg because it doesn't apply to subnets on routers.
Change-Id: I82796804a06e758e458606dc9eb400bcd08ad6e4
Using the same name for two different subnet pools means that one needs
to reference them by their UUID. Choosing unique names will allow us to
use the name to reference the pool later on.
At the same time simplify the command used for pool creation by
instructing OSC to only output the value that we are interested in.
Change-Id: Idedcb6328925d44cdd0f415450ec4ebbc272401d
While configuring the external network as the default
router gateway for IPV6 in lib/neutron_plugins/services/l3,
"router" keyword is missing in the command.
Corrected the command.
Change-Id: I055bea5137a841f709d4865ec9a43d6b53f8f4c9
Closes-Bug: 1660712
$ipv6_modes should always be passed when creating the
default IPv6 subnet, not just when fixed_range_v6 is
set. Without it the default was DHCPv6, which cirros
doesn't support out of the box. Was broken in
change-over from neutron to openstack cli.
Change-Id: Iadd39b1ce02fe0b3781bd3ae04adfd20d7e12d9f
Closes-bug: #1656098
The intent was to make any ipv6 safe addr range bigger than a /64 a /64
when setting the fixed range. Unfortunately the awk only emited the mask
and not the addr. Fix this by sprinkling the address back in.
Fixes-Bug: 1643055
Change-Id: I526d4c748fd404ecb3c77afcbb056aa95090c409
Currently devstack assumes that the network used for ssh
validation is the private network. This patch adds a hook that
sets the network used for ssh validation based on whether or not
provider networking is being used. It also moves the function
'is_provider_network' into functions-common as it will now be
used by both tempest and neutron.
Change-Id: I265c9e26c9bfb18b7e201f27d8912b8bec235872
The switch to using subnetpools caused quite a bit of confusion
because it didn't respect the value of FIXED_RANGE. This caused
conflicts in the gate with it's default IPv4 value of 10.0.0.0/8.
This patch does a few things to address the issue:
* It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE
values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values
to dervive from them by default.
* This addresses the concern that was raised about implying that
SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting
SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value
for the operator specify a chunk of addresses that are safe to
use for private networks without implementation implications.
* Backwards compatibility is maintained by alloing users to override
override all of these values.
* The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24
* Because we want to be able to use subnetpools for auto allocated
topologies and we want to be able to have a large chunk of
instances on each network, we needed a little more breathing room
in the default v4 network size.
* SUBNET_POOL_SIZE_V4 default is changed from 24 to 26
* In conjuction with this change and the one above, the default
subnetpool will support up to 16 64-address allocations.
* This should be enough to cover any regular gate scenarios.
* If someone wants a bigger/smaller subnet, they can ask for that
in the API request, change this value themselves, or use a different
network entirely.
* FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE
* This avoids the private subnet in the non-subnetpool case from being
larger than /64 to avoid issues identified in rfc 7421.
* Users can still explicitly set this value to whatever they want.
This 'max' behavior is only for the default.
* This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves
tons of room for v6 subnetpools.
Closes-Bug: #1629133
Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
This removes the logic to add a route pointing to the IPv4
tenant private network range since the router is performing
SNAT. If reaching the IPs via the route worked at all, it was
by accident since this behavior is certainly not guaranteed
by Neutron.
Change-Id: If45e3fc15c050cfbac11b57c1eaf137dd7ed816f
The neutron client is going to be deprecated during the
Ocata timeframe, so it is time to start switching to the
openstack client to invoke networking commands.
use of neutron client in neutron-legacy has been left as is.
The command for setting the router gateway is left as follow up.
Change-Id: I0a63e03d7d4a08ad6c27f2729fc298322baab397
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
This fix replaces Q_USE_PROVIDERNET_FOR_PUBLIC with
Q_USE_PROVIDER_NETWORKING in the error messages introduced by
[1].
The error is thrown when provider networking with IPv6 has been
requested via local.conf, but no provider IPv6 range or provider
IPv6 gateway is provided. But if a provider network should be used
over the private network is determined along the variable
Q_USE_PROVIDER_NETWORKING and not Q_USE_PROVIDERNET_FOR_PUBLIC.
The variable Q_USE_PROVIDERNET_FOR_PUBLIC determines if a provider
network should be used as public network. This happens a few lines
later in the code and is not related to those error messages.
[1] https://review.openstack.org/#/c/326638/1/lib/neutron_plugins/
services/l3
Change-Id: I50aa1e9d2027eef598c95404851e51c31a397fbb
Some of the clouds used for CI use the 10.2xx.0.0/16 range
for VMs, and collide with the wider 10.0.0.0/8.
This setting allows for creation of 256 subnets out of the pool.
Change-Id: I48c86f94098f1501f0e7f90a265dda7e81440eb0
Closes-Bug: 1629133
Added an option to make subnetpools to be optional
as it ignores the public network specified in
FIXED_RANGE.
DocImpact
Change-Id: Ic89ceca76afda67da5545111972c3348011f294f
Closes-Bug: #1628267
When dots are used with sysctl, they are reinterpreted as slashes.
Route devices can have dots in their names, so when they are used in a
sysctl command that also uses dots, its dot will be replaced with a
slash, causing an error.
Change-Id: Ie32126a3aa8d646568d7d37ec4874419b9658935
Closes-Bug: #1627770
The motivation is to make it more friendly with lib/neutron.
ie. independent from lib/neutron-legacy
Change-Id: I19821b009cbf1bc715a6c7b2854e4c77d2041ec4
Some systems may have more than one default route.
Set up iptables NAT rules on all v4 default route devices.
Accept RAs on all v6 default route devices.
Closes-Bug: #1624773
Change-Id: If58509297497ea33c6c156f083a4394000bd0561
p-c patches have merged, neutron-lbaas removal is in the merge queue.
This reverts commit b3f26cb66c70b599c4d77945f2bdadd9537c7c35.
Depends-On: I506949e75bc62681412358ba689cb07b16311b68
Change-Id: I98d62c13ef90b20a9c67ef4f1720efcaa366fb31
Because neutron sets ipv6 forwarding settings, we stop accepting RAs
from IPv6-only host environments. This leads to a loss of external
connectivity, which is bad for zuul running tests and stuff.
Setting accept_ra to 2 will cause the RAs to be accepted.
Change-Id: Ia044fff2a1731ab6c04f82aea47096b425e0c0a0
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
By default, FIXED_RANGE and NETWORK_GATEWAY (and the
IPv6 equivalents) are in the same subnet. But if
FIXED_RANGE is over-ridden in local.conf we could
create a subnet with an invalid gateway address.
Since neutron will pick the lowest host IP as the
gateway by default, do not specify them unless the
user has specifically set them.
Do this for both the private and public subnets, as
well as the public IPv4 subnet.
Change-Id: Ifc71400a3af1f131bb8a9722188e13de5bd3c806
The plugin creates subnetpools but does not use them when creating the
default subnets. It uses CIDR values that overlap with the
default pools. Change this to use the subnetpools.
Change-Id: I6171c13507e420f146801d323cb1011be36c1e8c
Closes-bug: 1613717
===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
nova-net is deprecated, and it's long time to switch to neutron by
default. This patch does that, and has an auto configuration mode that
mostly just works for the basic case.
It does this by assuming that unless the user specifies an interface
for it to manage, that it will not automatically have access to a
physical interface. The floating range is put on br-ex (per normal),
fixed ranges stay on their OVS interfaces.
Because there is no dedicated interface managed by neutron, we add an
iptables rule which allows guests to route out. While somewhat
synthetic, it does provide a working out of the box developer
experience, and is not hugely more synthetic then all the other
interface / route setup we have to do for the system.
You should be able to run this with a local.conf of just
[[local|localrc]]
ADMIN_PASSWORD=pass
DATABASE_PASSWORD=pass
RABBIT_PASSWORD=pass
SERVICE_PASSWORD=pass
And get a working neutron on a single interface box
Documentation will come in subsequent patches, however getting the
code out there and getting feedback is going to help shape this
direction.
Change-Id: I185325a684372e8a2ff25eae974a9a2a2d6277e0
Relying on 'external_network_bridge=br-ex' for the L3
agent has been deprecated in Neutron. This patch adjusts
the devstack defaults to setup Neutron in the preferred
manner (empty external_network_bridge value and
correct bridge_mappings for the L2 agent).
This will also help with correct MTU calculations now that
the external network will have the correct segmentation
type on it ('flat' now instead of 'vxlan' by default).
Related-Bug: #1511578
Related-Bug: #1603493
Change-Id: Id20e67aba5dfd2044b82c700f41c6e648b529430
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