Commit 90212b12 changed the OVS agent so adding vital drop flows on
br-int (table 0 priority 2) for packets from physical bridges was
deferred until DVR initialization later on. But if br-int has no flows
from a previous run (eg after host reboot), then these packets will hit
the NORMAL flow in table 60. And if there is more than one physical
bridge, then the physical interfaces from the different bridges are now
essentially connected at layer 2 and a network loop is possible in the
time before the flows are added by DVR. Also the DVR code won't add them
until after RPC calls to the server, so a loop is more likely if the
server is not available.
This patch restores adding these flows to when the physical bridges are
first configured. Also updated a comment that was no longer correct and
updated the unit test.
Change-Id: I42c33fefaae6a7bee134779c840f35632823472e
Closes-Bug: #1887148
Related-Bug: #1869808
(cherry picked from commit c1a77ef8b7)
(cherry picked from commit 143fe8ff89)
(cherry picked from commit 6a861b8c8c28e5675ec2208057298b811ba2b649)
In versions prior to Train, the "keepalived-state-change" monitor
does not format correctly the log messages. That happens when the
"Daemon.run()" method executes "unwatch_log". After the privileges
are dropped, the logging should be configured again.
Change-Id: Ief52fac479d4b3cfa5f90118235c241a14b1011f
Closes-Bug: #1886216
When the vlan and vxlan both exist in env, and l2population
and arp_responder are enabled, if we update a port's ip address
from vlan network, there will be arp responder related flows
added into br-tun, this will cause too many arp reply for
one arp request, and vm connections will be unnormal.
Closes-Bug: #1824504
Change-Id: I1b6154b9433a9442d3e0118dedfa01c4a9b4740b
(cherry picked from commit 5301ecf41b)
This resolves a bug that causes stale records to be kept in place when
an admin deletes a port, server or floating IP that was created in some
project other than the admin project.
Change-Id: I7cbb0e87a7e87f23ccf5d8750835b4785693473a
Closes-Bug: #1875981
(cherry picked from commit 622714b63e)
New versions of isort broke pylint. This patch fixes it at 4.3.21.
Depends-On: https://review.opendev.org/739914
Change-Id: Ic6858b60ae6b7cd031843ea594b8fe1c8a67bb54
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 75970c4cda)
In case when related dvr router is configured by L3 agent, it is first
added to the tasks queue and then processed as any other router hosted
on the L3 agent.
But if L3 agent will ask neutron server about details of such router,
it wasn't returned back as this router wasn't really scheduled to the
compute node which was asking for it. It was "only" related to some
other router scheduled to this compute node. Because of that router's
info wasn't found in reply from the neutron-server and L3 agent was
removing it from the compute node.
Now _get_router_ids_for_agent method from the l3_dvrscheduler_db module
will check router serviceable ports for each dvr router hosted on the
compute node and will then find all routers related to it. Thanks to
that it will return routers which are on the compute node only because
of other related routers scheduled to this host and such router will not
be deleted anymore.
Change-Id: I689d5135b7194475c846731d846ccf6b25b80b4a
Closes-Bug: #1884527
(cherry picked from commit 38286dbd2e)
This reverts commit 9313dce459.
NOTE(elod.illes): devstack in Rocky is fixed and grenade jobs started
to pass. We can enable grenades again to restore testing as it was
before.
Change-Id: Ibd085a563b89c117e1e9a9c112a7d15cc2ecbc3e
This option allows to configure Number of times nova or ironic client
should retry on any failed http call.
Default value for this new option is "3".
Conflicts:
neutron/notifiers/ironic.py
Change-Id: I795ee7ca729646be0411a1232bf218015c65010f
Closes-Bug: #1883712
(cherry picked from commit e94511cd25)
Method _ensure_default_security_group wasn't atomic as it first tries to get
default SG and if that not exists in DB, it tries to create it.
It may happend, like e.g. in Calico plugin that between
get_default_sg_id method and create_security_group method, this default
SG will be created by other neutron worker. And in such case there will
be Duplicate entry exception raised.
So this patch is adding handling of such exception.
Conflicts:
neutron/db/securitygroups_db.py
Change-Id: I515c310f221e7d9ae3be59a26260538d1bc591c2
Closes-Bug: #1883730
(cherry picked from commit 7019c5cf50)
In some cases it may be useful to log new vlan tag which is found
on the port when it losts old vlan tag which should is expected to
be there.
So this patch adds such value to the log message.
TrivialFix
Change-Id: I231e624f460510decc6d2237040c8bef207e2e8e
(cherry picked from commit 3ac63422ea)
The OVS DB "vsctl" implementation does not allow empty transactions.
In [1], if qos and queue are None, this transaction won't have any
operation. In "vsctl" implementation this will raise the following
exception:
Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: missing command
name (use --help for help)
[1]https://review.opendev.org/#/c/738171/1/neutron/agent/common/ovs_lib.py@914
Change-Id: Iece42986b32e774018affbbbe83923ce73590d77
Closes-Bug: #1885695
Block traffic between br-int and br-physical is over kill
and will at least
1. interrupt vlan flow during startup, and is particularly
so if dvr enabled
2. if let's rabbitmq is not stable, it is possible data plane
will be affected and vlan will never work.
Using openstack on k8s particularly amplifies the problem
because pod could be killed pretty easily by liveness
probes.
Change-Id: I51050c600ba7090fea71213687d94340bac0674a
Closes-Bug: #1869808
(cherry picked from commit 90212b12cd)
The need for this change stems from following issues:
1) When ovs_use_veth = False with ovs-dpdk issue with ovs
was observed - after vswitch restart interface is not comming up.
Meaning ovs-dpdk uses ovs internal ports and it is not able to bring
them up on restart.
2) When ovs_use_veth = True and ovs-dpkd is used, packets sent with
incorrect checksum due to the fact that ovs-dpdk does not do checksum
calculations for veth interface.
This commit allows to use second option and resolve checksum issue by
disabling checksum offload.
Closes-Bug: #1832021
Related-Bug: #1831935
Change-Id: Iecce8d2c6c2c46718cc1020c6e8f914cd4560e4b
(cherry picked from commit 11838a2bc5)
When a Port is deleted, the QoS extension will reset any rule (QoS
and Queue registers) applied on this port or will reset the
related Interface policing parameters.
If the Port and the related Interface are deleted during the QoS
extension operation, those commands will fail. This patch makes those
operations more resiliant by not checking the errors when writing on
the Port or the Interface register.
Change-Id: I2cc4cdf5be25fab6adbc64acabb3fffebb693fa6
Closes-Bug: #1884512
(cherry picked from commit e2d1c2869a)
(cherry picked from commit 84ac8cf9ff)
(cherry picked from commit 3785868bfb)
As discussed in ML thread[1], we are going to
make grenade jobs as non voting for all EM stable and
oldest stable. grenade jobs are failing not and it might take
time to fix those if we are able to fix. Once it jobs are
working depends on project team, they can bring them back to
voting or keep non-voting.
If those jobs are failing consistently and no one is fixing them
then removing those n-v jobs in future also fine.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015499.html
StableOnly
Change-Id: Ie846a8cb481da65999b12f5547b407cc7bdc3138
Adds support for rpc_response_max_timeout in LB-agent.
Change-Id: I1c5dcd1642019cb8c327722819f753b2b5b7137c
Closes-Bug: #1880934
(cherry picked from commit edfe7daf04)
Neutron-ovs-agent can now enable IGMP snooping in integration bridge
if config option "igmp_snooping_enable" in OVS section in config will
be set to True.
It will also set mcast-snooping-disable-flood-unregistered=true
so flooding of multicast packets to all unregistered ports will be
disabled also.
Both changes are applied on integration bridge.
Change-Id: I12f4030a35d10d1715d3b4bfb3ed5efb9aa28f2b
Closes-Bug: #1840136
(cherry picked from commit 5b341150e2)
This patch ensures that the ovsdb monitor propagates the events
received for modified ports.
We'll use a new list for the modified ports, which the neutron ovs
agent can handle.
In particular, this will cover the situation in which the ofport
changes. When using recent OVS Windows versions, VM ofports change
to -1 (invalid) when the VMs are shut down, receiving a valid
ofport when the VMs are powered back on (different than the initial
one). With this patch applied, "modify" events will be propagated
to the ovs agent, which will then update the OpenFlow rules.
The old rules are cleaned up by "update_stale_ofport_rules"
once the invalid ofport is detected.
Closes-Bug: #1843870
Co-authored-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Conflicts:
neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
Change-Id: I0c3a570cbb3fbb03b4224744b32e034e9e255f8e
(cherry picked from commit 451c21571f)
(cherry picked from commit 4991325054)
In case when physical bridge is removed and created again it
is initialized by neutron-ovs-agent.
But if agent has enabled distributed routing, dvr related
flows wasn't configured again and that lead to connectivity issues
in case of DVR routers.
This patch fixes it by adding configuration of dvr related flows
if distributed routing is enabled in agent's configuration.
It also adds reset list of phys_brs in dvr_agent. Without that there
were different objects used in ovs agent and dvr_agent classes thus
e.g. 2 various cookie ids were set on flows in physical bridge.
This was also the same issue in case when openvswitch was restarted and
all bridges were reconfigured.
Now in such case there is correctly new cookie_id configured for all
flows.
Change-Id: I710f00f0f542bcf7fa2fc60800797b90f9f77e14
Closes-Bug: #1864822
(cherry picked from commit 91f0bf3c85)
In case when neutron-ovs-agent will notice that any of physical
bridges was "re-created", we should also ensure that stale Open
Flow rules (with old cookie id) are cleaned.
This patch is doing exactly that.
Change-Id: I7c7c8a4c371d6f4afdaab51ed50950e2b20db30f
Related-Bug: #1864822
(cherry picked from commit 63c45b3766)
In the patch [1] we changed definition of the abstract method
"plug" in the LinuxInterfaceDriver class.
That broke e.g. 3rd-party drivers which still don't accept this
new parameter called "link_up" in the plug_new method.
So this patch fixes this to make such legacy drivers to be still working
with the new base interface driver class.
This commit also marks such definition of the plug_new method as
deprecated. Possibility of using it without accepting link_up parameter
will be removed in the "W" release of the OpenStack.
[1] https://review.opendev.org/#/c/707406/
Change-Id: Icd555987a1a57ca0b31fa7e4e830583d6c69c861
Closes-Bug: #1879307
(cherry picked from commit 30d573d5ab)
(cherry picked from commit 9c242a0329)
Although notify_nova_on_port_status_changes defaults to true, it
could be to false, making the nova_notifier attribute unsafe to
use without checking.
This patch checks both the config option and that the attribute
exists, since the config could be changed after the plugin is
already initialized without the nova_notifier attribute being set.
Change-Id: Ide0f93275e60dffda10b7da59f6d81c5582c3849
Closes-bug: #1843269
(cherry picked from commit ab4320edb4)
The 2.6.0 version introduces some checks that cause failures
with the current code. To avoid that, cap pycodestyle to a
version that had been tested without errors.
Conflicts:
test-requirements.txt
Change-Id: I00a35884b14af3e2cf751c04312c847ecfe658c7
(cherry picked from commit 719cae183a)
[0] introduced the concept of connected routers: routers that are
connected to the same subnets. When a L3 agent is synching a router
with connected routers, the data of the entire set should be returned
to the agent by the Neutron server.
However, if an agent tries to synch a router with
no connected routers when the same agent has other routers that are
connected among them, the Neutron server returns the former and the
latter. For details of how this bug can manifest itself, please see [1].
This change prevents this situation: only the synched router is
returned.
[0] https://review.opendev.org/#/c/597567
[1] https://bugs.launchpad.net/neutron/+bug/1838449/comments/15
Change-Id: Ibbf35d0f4a0bf9281f0bc8c411e8527eed75361d
Closes-Bug: #1838449
(cherry picked from commit 48ea7da6c5)
When "network_segment_range" service extension is enabled, the default
(shared) network segment range could not exist. In this case, when
retrieving the segmentation IDs, the existance of this range should be
checked first.
Conflicts:
neutron/objects/network_segment_range.py
Change-Id: Iaff891a48adc811ab114fb03b24ab3da9311eec3
Closes-Bug: #1870569
(cherry picked from commit 2e6aa290a3)
(cherry picked from commit 222beb3a8d)
Fixed the queries to retrieve the segment ID allocations when service
plugin network_segment_range is enabled. With the previous
implementation, a project user was able to allocate a segment ID
belonging to other project segment range.
The solution implemented was discussed in [1]:
- A project user will retrieve segments from the project ranges.
- When depleted, the segment IDs will be retrieved from the shared
range, never using another project segment ID.
[1]http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012736.html
Conflicts:
neutron/objects/network_segment_range.py
neutron/objects/plugins/ml2/base.py
neutron/objects/plugins/ml2/vxlanallocation.py
neutron/objects/plugins/ml2/vlanallocation.py
neutron/tests/unit/objects/test_network_segment_range.py
Change-Id: I953062d9ee8ee5ee9a9f07aff4a8222ac63ed525
Closes-Bug: #1863423
(cherry picked from commit 046672247d)
(cherry picked from commit bbe401aaf9)
Darragh O'Reilly
Zuul
Rodolfo Alonso Hernandez
Yang Li
Jens Harbott
Lucas Alvares Gomes
Slawek Kaplonski
Elod Illes
shenjiatong
Alexander Vlasov
Ghanshyam Mann
Tamerlan Abu
Lucian Petrut
Brian Haley
Dongcan Ye
Miguel Lavalle