When the HA attribute of the router changes, the code determines
whether the gateway in memory is consistent with the gateway
in the database to decide whether it needs to be reconfigured.
But there are problems with the judging conditions.
After the HA attribute of the router changes, the relevant parameters
of gateway port will be updated by ML2 agent,
including "binding:host_id"、"updated_at" and "revison_number".
Method "_gateway_ports_equal" removes
only the "binding:host_id" property of the port,
resulting in unequal results for each decision
Change-Id: I19e024ff360611d191da2bd3bff1b86abe1a8ea1
Closes-Bug: 1797298
The bulk port creation scenario requires the ability to generate
multiple MAC addresses for the bulk added ports. This change leverages
the code added in [1] to make bulk MAC creation available.
[1] https://review.openstack.org/510830
Implements: blueprint speed-up-neutron-bulk-creation
Depends-On: https://review.openstack.org/613149
Change-Id: Ia769dadf69781ba511a19c52998949b668963a19
This patch changed the old engine facade to new engine
fade in neutron/db/agents_db.py.
Partially-Implements blueprint: enginefacade-switch
Change-Id: Iee6fbee98fae41d75b4e8eb0fbcf2283da545023
If the host OS is using an older kernel and invoke the compile_ovs
function from the DevStack OVS library (devstack/lib/ovs), that function
will try to install the kernel-dev and kernel-headers package even if
the "build_modules" parameter is set to False.
That could fail because the specific kernel-* packages for the version
of the kernel running may not be present in the distro's repository
anymore. Plus, if the kernel modules will not be compiled, there's no
reason to install such packages.
This patch is fixing this problem by using the "build_modules" parameter
as a flag to whether install or not those kernel-* packages.
Change-Id: I11af0e22d25973e6334e867ab2659fbdf9f10d86
Closes-Bug: #1802101
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
There was missing step about adding underlying interface to the
provider bridge in ovs deployment guides.
This patch adds this missing step.
Change-Id: I2ef5f12c469647d7f197cb5db71692e68d23f718
Closes-Bug: #1801361
In test test_ha_router_namespace_has_ipv6_forwarding_disabled
functional test it may happen that L3 agent will not change ipv6
forwarding and test fails because it checks that only once just
after router state is change to master.
This patch fixes that race by adding wait for 60 seconds to
ipv6 forwarding change.
Change-Id: I85a602561ebe9b7ab135913af49a3f010b09f196
Closes-Bug: #1801930
The MAX_RETRIES constant from neutron.db.api is available in neutron-lib
and is already used by most of the code today. This patch changes the
remaining references over to use lib's constant and removes the
MAX_RETRIES from neutron.db.api
NeutronLibImpact
Change-Id: I79480daca9cca3d4e1504767d286aab22504e0b9
This patch updates minimal required versions of
oslo.concurrency
oslo.config
to be same as in neutron-lib.
Change-Id: I2a2f68731445634b2599f27b3146c1bff31cb0c9
Now supported_vnic_types is hardcoded to the mechanism drivers, but that
can depend on several factors, like type of the NIC, admin decision,
etc.
With this patch we put the right to decide which vnic types are
supported for ovs agent into the hands of the admin, by allowing
blacklisting items from the mechanism driver specific list.
Background: http://eavesdrop.openstack.org/meetings/neutron_qos/2018/
neutron_qos.2018-07-31-15.00.log.html#l-58
Change-Id: Iad9e2e966df53b4164d2a56a93215c69825b5241
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
In patch [1] timeout for
- tempest-full
- tempest-full-py3
was increaced to 3h.
Unfortunatelly it was done only for check queue.
I forgot to do the same change for jobs in gate queue
This patch adds same change for gate queue.
[1] https://review.openstack.org/#/c/614423/
Change-Id: I263124aa732efea8295313aeff7697b91c00f3f4
Floating IP port forwarding internal or external port number should
not allow 0, otherwise you will get some ValueError exception in
neutron server.
Change-Id: I8bf8ed6f9c4b937743f8c0f998ee897e3af17459
Closes-Bug: #1799150
The first device the agent happens to pick could be something
without a MAC address like a 6in6 interface. This was causing
the agent to fail to start if it was unlucky enough to pick
that address.
This patch just adjusts the logic to keep iterating through
the list until we find a MAC.
Change-Id: Iba9c7c3cb200e74a78ea885e8d9323de64c2c663
Closes-Bug: #1801030
In case when 2 dvr routers are connected to each other with
tenant network, those routers needs to be always deployed
on same compute nodes.
So this patch changes dvr routers scheduler that it will create
dvr router on each host on which there are vms or other dvr routers
connected to same subnets.
Co-Authored-By: Swaminathan Vasudevan <SVasudevan@suse.com>
Closes-Bug: #1786272
Change-Id: I579c2522f8aed2b4388afacba34d9ffdc26708e3
The functionality allowing to disable DNS server announcement from the
DHCP agent for certain subnets was introduced in [0]. We should mention
this feature in the corresponding documentation.
[0] https://review.openstack.org/495781
Change-Id: I4adfa7ba789a59f967297ebb6c571deb0652c7ca
Related-Bug: 1311040
Current DHCP port management in Neutron makes the server to clear the
device_id while the agent is responsible for setting it.
This may cause a potential race condition, for example during network
rescheduling. The server aims to clear the device_id on a DHCP port and
assign the network to another agent while the old agent might just be
taking possession of the port. If the DHCP agent takes possession of the
port (i.e., update port...set the device_id) before the server clears
it, then there is no issue. However, if this happens after the clear
operation by server then the DHCP port would be updated/marked to be
owned by the old agent.
When the new agent takes over the network scheduled to it, it won't be
able to find a port to reuse so that an extra port might need to be
created. This leads to two issues:
1) an extra port is created and never deleted;
2) the extra port creation may fail if there are no available IP
addresses.
This patch proposes a validation check to prevent an agent from updating
a DHCP port unless the network is bound to that agent.
Co-authored-by: Allain Legacy <Allain.legacy@windriver.com>
Closes-Bug: #1795126
Story: 2003919
Change-Id: Ie619516c07fb3dc9d025f64c0e1e59d5d808cb6f
For jobs:
- tempest-full
- tempest-full-py3
Sometimes we hit timeouts which aren't related
directly to Neutron.
So, as was done for some other jobs in [1] it will also
increase timeout for tempest-full jobs.
This patch adds also our own list of irrelevant files for
tempest-full-py3 job as it wasn't specified before.
[1] https://review.openstack.org/#/c/613234/
Change-Id: I6e56b5f9243cdc29e8a36399ae98f95173e61c98
Free subnet can not remove from router if other router's
subnets have port_forwarding. This patch fixed it by
checking the router interface subnet and IP address.
Co-Authored-By: LIU Yulong <i@liuyulong.me>
Closes-Bug: #1799140
Change-Id: Idace35126bb00139fa1f9f48be3aa3aab265b9d8
An event will be sent out after creating
router gateway. Within the event, ext_ips
is sent incorrectly while gw_ips is expected.
Project neutron-dynamic-routing subscribes
the topic and will process the event. But
it can't process ext_ips.
This commit gets the gw_ips through the
ext_ips and sends gw_ips out.
Co-Authored-By: Allain Legacy<Allain.legacy@windriver.com>
Change-Id: I9b67b58e87faa9cbb8ed4cd03c74f467ca20d73f
Closes-Bug: #1796629