Neutron migrated from using ofctl from the command line in Pike.
This patch refactors DSCPs OvS backend to use native rather than
ofctl and deprecates the run_ofctl function in ovs_lib.OVSBridge.
Change-Id: Id9ab0eaf92b6ec6d5c9197bee60d324ffcb192a8
Related-Bug: #1853171
This patch is moving the DevStack module to deploy OVN to the Neutron
DevStack plugin.
As a first step, this plugin will continue to use the
openstack/networking-ovn repository and, as we advance into the mergings
steps we will modify this plugin (just few lines) to use the code in
the Neutron repository itself.
TODO's where left in the code on top of all the bits that will change
once the networking-ovn code is merged into Neutron.
Below is a snippet of the what needs to be enabled in local.conf to get
OVN deployed:
[[local|localrc]]
enable_plugin neutron https://opendev.org/openstack/neutron
Q_AGENT=ovn
Q_ML2_PLUGIN_MECHANISM_DRIVERS=ovn,logger
Q_ML2_PLUGIN_TYPE_DRIVERS=local,flat,vlan,geneve
Q_ML2_TENANT_NETWORK_TYPE="geneve"
Partially-Implements: blueprint neutron-ovn-merge
Change-Id: I24ab11ab923339959eecfbaed79a3ceadc4a87f4
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
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
In comments given automatically by abandon_old_reviews.sh script
there was still Jenkins mentioned as CI tool.
We are using Zuul for very long time and "zuul" user is voting
now instead of "jenkins" so this patch updates those commit
messages to make this messages correct.
TrivialFix
Change-Id: Iad119108ea82b47ac2a66b9f6f8a8bb56b57e7b6
Before this patch function get_value_from_file() was only
logging something like "Unable to access {filename}" but it
would be useful sometimes to check what was exact reason of
IOError so lets log this info also.
TrivialFix
Related-bug: #1853652
Change-Id: I28b1753a8d5767babbb6f06a581ffe1fc4ad75d3
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
We have run neutron-grenade-multinode in both check and gate queues
already. This job is almost the same as grenade-py3. The only difference
from Neutron pov is that neutron-grenade-multinode is multinode job and
grenade-py3 is single node job.
So we agreed on last Neutron CI meeting [1], that there is no need to
run both of those jobs.
As grenade-py3 is part of integrated-gate-networking template together
with tempest-integrated-networking job this patch removes also
integrated-gate-networking template from neutron's zuul config and adds
only tempest-integrated-networking to both check and gate queues.
[1] http://eavesdrop.openstack.org/meetings/neutron_ci/2019/neutron_ci.2019-11-19-16.00.log.html#l-179
Change-Id: Ic2e7ca04929dc89a2e408465eb34ef3feec2e328
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 cae66a4d8d13deda74db806d733c2ac39ea2e849.
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