This patch imports ovsdb related code from networking_ovn.
Previous paths in networking-ovn tree:
./networking_ovn/ovsdb/commands.py ->
./neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/commands.py
./networking_ovn/ovsdb/worker.py ->
./neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/worker.py
./networking_ovn/ovsdb/ovn_api.py ->
./neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/api.py
ACL commands will be implemented when the related code is merged and
could be tested properly.
Related-Blueprint: neutron-ovn-merge
Co-Authored-By: Reedip <rbanerje@redhat.com>
Co-Authored-By: Numan Siddique <nusiddiq@redhat.com>
Co-Authored-By: Flavio Fernandes <flaviof@redhat.com>
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Co-Authored-By: Changxun Zhou <zhoucx@dtdream.com>
Co-Authored-By: Gal Sagie <gal.sagie@huawei.com>
Co-Authored-By: Amitabha Biswas <abiswas@us.ibm.com>
Co-Authored-By: Richard Theis <rtheis@us.ibm.com>
Co-Authored-By: lzklibj <lzklibj@cn.ibm.com>
Co-Authored-By: zhufl <zhu.fanglei@zte.com.cn>
Co-Authored-By: Na <nazhu@cn.ibm.com>
Co-Authored-By: Chandra S Vejendla <csvejend@us.ibm.com>
Co-Authored-By: Gary Kotton <gkotton@vmware.com>
Co-Authored-By: Aaron Rosen <aaronorosen@gmail.com>
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I9fe64f954d227efaab5e96c6150df44f36a2530a
The OVNRevisionNumbers maintenance methods are used to check
inconsistences between the Neutron and the OVN databases. Two
methods are implemented:
- get_inconsistent_resources: to retrieve those registers with
different revision number
- get_deleted_resources: to retrieve the list of OVNRevisionNumbers
orphan registers (the resource register is deleted).
Previous paths in networking-ovn tree:
./networking_ovn/db/maintenance -> ./neutron/db/ovn_revision_numbers_db
Co-Authored-By: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: I948af3d3b93731dbf0773615759b49bf6b4a8f5f
Partially-Implements: blueprint neutron-ovn-merge
OVNRevisionNumbers registers are used to check the synchronization
status of the objects handled by OVN, assigning a revision number
to those objects stored in the Neutron DB, also present in the OVN
one.
The methods implemented are:
- create_initial_revision
- delete_revision
- get_revision_row
- bump_revision
Partially-Implements: blueprint neutron-ovn-merge
Change-Id: I8a3bf9a915f6812db6e78a189127613a2fa204ae
OVNHashRing objects are used by OVN backend to register the nodes
controlled. The methods implemented are:
- add_node: including the group_name and optionally the node_uuid
- remove_nodes_from_host: remove all nodes maching a hostname and
group_name
- touch_nodes_from_host: update a OVNHashRing register timestamp,
filtering by hostname and group_name
- touch_node: update a OVNHashRing register timestamp, filtering by
node_uuid
- get_active_nodes: retrieve any active node (filtering timestamp),
group_name and hostname
Previous paths in networking-ovn tree:
./networking_ovn/db/hash_ring.py -> ./neutron/db/ovn_hash_ring_db.py
./networking_ovn/tests/unit/db/test_hash_ring.py ->
./neutron/tests/unit/db/test_ovn_hash_ring_db.py
Co-Authored-By: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: Ibb9c79771c48ccde564c39be9d781f3720802a2d
Partially-Implements: blueprint neutron-ovn-merge
Add a new DB table "network_subnet_lock". The primary key will be the
network_id. When a subnet is created, inside the write context during
the "subnet" object creation, a register in the mentioned table is
created or updated. This will enforce the serialization of the "subnet"
registers belonging to the same network, due to the write lock in the
DB.
This will solve the problem of attending several "subnet" creation
requests, described in the related bug. If several subnets with the
same CIDR are processed in parallel, the implemented logic won't reject
them because any of them will not contain the information of each other.
This DB lock will also work in case of distributed servers because the
lock is not enforced in the server logic but in the DB backend.
Change-Id: Iecbb096e0b7e080a3e0299ea340f8b03e87ddfd2
Closes-Bug: #1852777
During e.g. migration or shelve of VM it may happend that
port update event will be send to the ovs agent and in the almost
the same time, port will be removed from br-int.
In such case during update_port_filter method openvswitch firewall
driver will not find port in br-int, and it will do nothing with it.
That will lead to leftover rules for this port in br-int.
So this patch adds calling remove_port_filter() method if port was
not found in br-int. Just to be sure that there is no any leftovers
from the port in br-int anymore.
Change-Id: I06036ce5fe15d91aa440dc340a70dd27ae078c53
Closes-Bug: #1850557
This commit adds an upgrade check for NIC switch agent
alerting operators to ensure relevant hosts have kernel >= 3.13.
This check is introduced due to recent cleanup in NIC switch
agent code.
As of U release, Supported CentOS major was updated to 8 so it
is not expected that any deployment will have hosts running
kernel < 3.13. This check is added as an extra precaution.
This check should be removed in 1-2 cycles. A TODO was added to
reflect that.
Change-Id: I34003b3c2f0ac23185d036c9e47dc1c8662d6ce7
Related-bug: #1841067
After this patch, during delete subnets with fixed ip, there are high
chances a subnet can't be found(because it just deleted) while
deleting another subnet and Raise BadRequest instead of Notfound.
The behavior change led to heat gate failure, since Heat expect to
see NotFound exception instead of BadRequest.
Also the error message is really confusing while delete subnets
(you can check out more detail in
https://storyboard.openstack.org/#!/story/2006962)
hence, I think to revert this patch will make sense to maintain the
behavior before a proper solution comes out.
Story: 2006962
Task: 37652
This reverts commit cae66a4d8d.
Change-Id: I9fc200de376668b662cd8c2bfba01483dc9bb677
Added "ovn_revision_numbers" and "ovn_hash_ring" DB tables and models.
Change-Id: I07237946af698816a4229efec16de8f8f8addee9
Partially-Implements: blueprint neutron-ovn-merge
Only check sg object is not enough, we should also
check sg'ports is {} or not. Otherwise the old conjunction
will still exist.
Change-Id: I10588e73a9da7fdd43677f9247c176811dd68c62
Closes-Bug: #1854131
During the OVN repository migration, the zuul jobs relaset to ovn
cannot be executed due to the DB redefinition. Once the OVN plugin is
totally migrated to Neutron, this job can be integrated as a in-tree
backend tempest job.
Change-Id: If1f0b0453d90eed27051fd516b95da32d4aa2afe
Partially-Implements: blueprint neutron-ovn-merge
Since dropping py2 support and adding a basepython setting to the global
tox testenv, tox complains about a basepython mismatch when the
installed python3 is python3.6 and the py37 environment is executed (or
vice versa). Setting ignore_basepython_conflict = True will avoid this
message and enforce the correct python version to be used.
Needs a bump in the minimum tox version supported.
See also [0].
[0] https://review.opendev.org/582392
Change-Id: I3d9beeaed104dcf12cfd97590b44c4003754b4e4
When ovn code will be in neutron tree already, during the upgrade
we need to be sure that networking-ovn wasn't installed previously or
if it was installed, it's db version is the latest one.
Otherwise neutron's alembic migration script will not work properly as
it will check that ovn tables exists so it will skip creating them, even
if those tables aren't in proper shape (from latest networking-ovn
head).
Change-Id: I8c7b8df934c8b53ea5bc02dc8134db838f5e105a
Related-Blueprint: neutron-ovn-merge
As networking-ovn driver is going to be in neutron tree now, lets move
also networking-ovn jobs definitions to the neutron repo.
Change-Id: Ie1c66c773ee2d217b25bd915189e56254744a3d4
Related-Blueprint: neutron-ovn-merge
This patch consumes the neutron-lib OVO common_types module by
removing it from neutron and switching imports over to use neutron-lib
instead.
NeutronLibImpact
Change-Id: Ic9819a27e3e72038b819ab2fe845c26fc63b26d5
Currently, if dhcp mapping from a network is removed, it is reassigned
to the network. This is because of the Network Scheduler's schedule
function, which considers balancing the networks with the agents, whether
enable_dhcp is set on its subnets or not. It does not take into account
the network_auto_schedule config option. This is particularly disturbing
when considering backends which have their provide their own DHCP.
With this patch, if network_auto_schedule is set to False, networks wont
be automatically scheduled to DHCP Agents. If DHCP is to be mapped to a
network, it can be mapped using the CLI itself.
While it may seem that this change is breaking what is already working,
but as mentioned earlier, if there are network backends which provide DHCP
support themselves, they wont need the automatic mapping, which the term
"network_auto_schedule" actually stands for.
Closes-Bug: #1647421
Change-Id: If1a6a2a174d0f737415efa2abce518722316a77b
Mathieu Rohon confirmed me that he is no longer working on those
projects and that we can remove him from this list.
Fortunately Lajos Katona offered that he is interested in maintaining
those projects so I also added him to the list of liuetenants for
both those projects.
Change-Id: I6693f8f844795daa1dd7ca7cdf99cfe07b7d8f18
If any of the processes, client or server, spawned by NetcatTester is
not present during the stop command (kill signal sent), by default the
method will not raise an exception.
Change-Id: If8cf47a01dc353734ad07ca6cd4db7bec6c90fb6
Closes-Bug: #1852869
Devstack is moving to py3 by default[1] and neutron-grenade
will fail. There are patches up to drop the neutron-grenade
job but those are not merged yet.
let's keep this job runnable by explicitly mention the py2
and dropping plan will continue as it is.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010938.html
Change-Id: I086b5eee710b80e95703abb46a076aff5b7741f2
Now that we are using gitea the contents of our README.rst are
more prominently displayed. Starting it with a "Team and repository
tags" title is a bit confusing. This change makes it start with the
name of the project instead.
While at it, also fix the intro and the CONTRIBUTING.rst mention,
for clarity.
Change-Id: Ibf4ae411d756744727a0aee24efdbdd561d0f522
This job is running on python 2.7. We already removed all other jobs
which runs on python 2.7 and this was last one leftover.
There is other job "grenade-py3" which is basically the same but runs
using python 3 and this is still running on neutron's check and gate
queues.
This patch don't remove definition of neutron-grenade job as this job
is used by various different projects. So we need first to switch all
those projects to use grenade-py3 and than remove definition of
neutron-grenade.
Change-Id: I873bb63fa0456fd9c0fb9b037280fe8d2c0541d5
This patch switches neutron-tempest-with-os-ken-master to zuul v3
syntax.
It also switches this job to only run networking related tests instead
of full tempest test suite.
Change-Id: I4e9aa4bbafed4de0e3c13ece44f8e700952da568
Rodolfo Alonso Hernandez
Maciej Józefczyk
Zuul
Slawek Kaplonski
Adrian Chiris
Rico Lin
Yang Li
Jens Harbott
Boden R
Reedip
Ghanshyam Mann
Thierry Carrez
zhouhenglc