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
Set floating IP's router_id when it has port_forwardings
during the update API.
Co-Authored-By: chenguobin <chengb@chinatelecom.cn>
Closes-Bug: #1799135
Change-Id: Idb1a52b6f32bdb18d920bce2b891b4d73c557dfb
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
CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH were added
(like in nova) to fix agents on kernel 4.15.
Please see bug for details
Change-Id: Ieed6f5f6906036cdeaf2c3d96350eeae9559c0c7
Closes-Bug: #1800157
The DHCP agent will resync its state with Neutron to recover from any
transient notification or RPC errors. Currently, the periodic resync
task waits on a timer to determine whether a re-sync is necessary. The
interval between attempts by default is 5 seconds and can be longer
thru config. This may cause a potentially long delay before an agent
gets new work via an agent_updated RPC call.
The idea of this RFE is to change the timer based periodic resync task
into an event driven one. It also proposes a new DHCP agent config
option "resync_throttle" to ensure the minimum interval taken between
resync state events to avoid too frequent resyncing. In this way, we
could force the agent to act on the resync request immediately therefore
decreasing how much time is needed before DHCP services are available.
Co-authored-by: Allain Legacy <Allain.legacy@windriver.com>
Closes-Bug: #1780370
Change-Id: Ie9d758ba5f750a38dc19ea5ce8b2c6b414f9ef80
Make the same status information available to notification consumers
(resource==agent, event==after_create/after_update) as it was already
available where the notification is sent in class AgentDbMixin.
Change-Id: Ie74091da934c7e49fd29ae4c6f930a7eb47e14b2
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
This adds basic framework for neutron-status upgrade check commands.
For now it has only "check_nothing" check implemented.
Real checks can be added to this tool in the future.
Depends-On: https://review.openstack.org/#/c/610061/
Change-Id: Ib08119e1bb8de80856edb6a39769d4bc9d98c587
Story: 2003657
Task: 26144
There are a handful of functions in neutron.db.api that are no longer
used due to the consumption of the db api from neutron-lib. This patch
removes them.
Removed:
- _copy_if_lds()
- add_to_rel_load_list()
- load_one_to_manys()
- LOG
Renamed:
- expire_for_fk_change is now named _expire_for_fk_change to indicate
it's private and should not be used by consumers.
NeutronLibImpact
Change-Id: Icbdad6712345d04b0b45194422cbe0813cd7e1e4
The neutron.db.api.context_manager already references neutron-lib's
context manager; so consumers of it are already using neutron-lib. This
patch switches neutron's references to the context_manager over to
use neutron-lib's directly rather than that in neutron.db.api.
NeutronLibImpact
Change-Id: I97120faeec73690592ed21a5ec3c6202f61e1429