As I will not be maintaining the ovn-octavia-provider, I
am removing my name from the list. Also, since I have
not been as active in L3 recently, update that as well.
Change-Id: Ie883044f3bedc09ff19c58ce90ab9fdc09b92e29
Use an OVSDB lock to ensure that only one worker tries to create
the neutron_pg_drop port group. This also waits pre_fork so that if
getting the port group fails, neutron exits instead of continuing
on without the port group being created.
It was previously possible that a server could create the port
group and we wouldn't get the update before trying to create it
ourselves and checking for its existence.
This also modifies the get_port_group method to use the built-in
lookup() which searches by name or uuid and can take advantage of
both indexing and newly added ovsdbapp wait for sync functionality.
Closes-Bug: #1934930
Change-Id: Id870f746ff8e9741a7c211aebdcf13597d31465b
This jobs is almost the same as tempest-slow-py3 since we switched
OVN to be default backend in Neutron. And that tempest-slow-py3 job
is used by many projects. So to avoid potential breaks of the gate for
other projects (like we did recently, see related bug for details)
let's make this job voting and gating.
As it is really used in many different projects as voting and gating
job already I don't think there is any issue with doing the same in
the Neutron gate.
Related-bug: #1936983
Related-bug: #1930402
Change-Id: I85d3830e9cc65162db846e4858871e1db547a04b
This reverts commit df5cb28737.
The reverted commit triggers the failure of tempest-slow-py3 job.
tempest-slow-py3 is equal to non-voting neutron-ovn-tempest-slow job
in the neutron CI. It is a non-voting job so the error was not detected
before merging it. To recover the tempest job in OpenStack wide,
this commit reverts it.
See http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023764.html
Closes-Bug: #1936983
Change-Id: Id8cdd9c69e4fef2d9c335447b498958add8b7816
The mechanism driver support VNIC types validation is done now in the
"SimpleAgentMechanismDriverBase" class __init__ method. If a subclass
needs to administratively prohibit any VNIC type supported by default,
"vnic_type_prohibit_list" must be passed to the base class __init__
call.
Related-Bug: #1578989
Change-Id: Ic25a8a7c716b4980ad2542b44519f77c6fdad309
Added a new OVN Client extension: OVNClientPlacementExtension. This
extension is in charge of handling the bandwidth information stored
in the OVN database, in the "Chassis" registers on the
"ovn-cms-options" dictionary.
Three new keys are created to store the resource provider information
needed to parameterize the network backend bandwidth information,
following the implementation done in OVS and SR-IOV:
- resource_provider_bandwidths
- resource_provider_inventory_defaults
- resource_provider_hypervisors
When the OVN Client is started, the Placement extension will check if
the "placement" extension is loaded. It will also create an event to
check any configuration change done in any "Chassis" register.
The Placement extension will read the initial configuration stored
in the OVN database and will populate it to Placement API, creating
the needed resource providers, traits and inventories.
NOTE: This patch belongs to a series of patches to implement
minimum bandwidth scheduling blueprint in OVN backend. The next
patch will make OVN backend scheduling aware using the information
stored in Placement API and the port information passed by Nova when
a VM is created.
Partial-Bug: #1578989
Change-Id: I8ba38b8ace8852009fba8712aafa9f88c2b93ccb
Instead of executing a subquery inside a select, use a proper filter
condition instead.
Closes-Bug: #1936675
Change-Id: I97e9ca244c0716510fcd4ec81d54046be9c5f8f8
This new context will have only two capabilities: CAP_NET_ADMIN
and CAP_SYS_ADMIN (for operations inside namespaces).
Change-Id: If9273db1a7ccdce3a81f68fce78408830e9c3d42
In an attempt to minimize the number of connections to the OVSDBs the
ML2/OVN driver stopped connecting to the OVN dbs if the Neutron worker
was a RpcWorker but, that introduced a regression for those using
ML2/OVN + Neutron DHCP agent (for baremetal provisioning).
Because the RpcWorker didn't have a connection to the OVN database the
Neutron DHCP agent wasn't able to create the DHCP port and failed with:
2021-07-13 13:36:18.116 17 ERROR neutron.plugins.ml2.managers if not
self._sb_ovn.chassis_exists(host):
2021-07-13 13:36:18.116 17 ERROR neutron.plugins.ml2.managers
AttributeError: 'NoneType' object has no attribute 'chassis_exists'
This patch adds the RpcWorker back to the list of workers that should
connect to the OVN databases.
Change-Id: I454f3b52376a02f6cc9ca9124083295631bd03d5
Closes-Bug: #1929633
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This reverts commit 66ac943b64.
Reason for revert: After discussions with the core reviewers for ML2/OVN
and Neutron folks about this configuration option we understood that we
should just enable RpcWorkers to connect to the OVN database by default
and later allow rpc_workers to be set to 0 in Neutron (for those looking
for optimizations and that don't need RpcWorkers in their deployment). So
I am proposing a revert for this configuration option.
Change-Id: I73ba195401fff9f832b84633398816383f710b23
It is possible for events from the nb/sb to fire before the opposite
db connection is made. These events can call back into driver code
which tries to access the other db before it is connected.
Closes-Bug: #1929197
Closes-Bug: #1928794
Closes-Bug: #1929633
Change-Id: If947581b90ced42981c4611c32de8f428a052c69
This patch changes the policy for updating routes to support ECMP,
and will now add ECMP routes to the Neutron router namespace when
there are multiple routes pointing to the same destination address.
Change-Id: I842c1408ee0235bc54441e9ed69c8b87ea30651b
Related-Bug: #1880532
This patch switches over to callback payloads for PORT
AFTER_DELETE events.
Some shims were removed.
Change-Id: If69e37b84fe1b027777b1d673b3d08a6651a979e
This patch sanitizes the MAC address coming from a user input:
- The "base_mac" address configuration parameter.
- The "port.mac_address" stored in the database, if the script
provided is not executed.
This patch relays on [1], that will sanitize any input coming from
the server API.
This patch adds a new script to sanitize all "port.mac_address"
registers stored in the dabatabase.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/788300
Related-Bug: #1926273
Change-Id: I8572906cc435feda1f82263fd94dda47fc1526e1
When the L3 agent starts, reads the floating IP rule priority from
a state file created by "FipRulePriorityAllocator". In case of not
having all floating IPs registers in this file, the method:
- Creates a new priority for this floating IP.
- Creates the "ip rule" in the namespace.
- Adds a new entry in "self.floating_ips_dict".
All "ip rules" present in the namespace that do not match the
registered fixed IP address ("from") and the priority assigned
are deleted.
Closes-Bug: #1891673
Closes-Bug: #1929821
Change-Id: Ia3fbde3304ab5f3c309dc62dbf58274afbcf4614
Router_info's _process_internal_ports() method is the one which is
manipulating router_info.internal_ports cache and network_update()
method from the L3 agent is relying on that Router_info's cache to
check if updated network is connected to the router or not.
So they shouldn't be run together as that may cause some race conditions
and unexpected issues, like e.g. described in the related bug.
Until now, network_update event was the only one which was processed
without using queue of events. And because of that such race condition
as described above were possible.
To fix that, this patch changes network_update method in the way that it
now adds update events for each router hosted by agent to the queue.
Those events for single routers are then processed, checks if network is
actually connected to the router and if yes, schedules router update to
be processed.
Closes-Bug: #1933234
Change-Id: I2efe66a7415f7a18fb85bd2536a1901e751d6203
Zuul
Eduardo Olivares
Brian Haley
Terry Wilson
Nurmatov Mamatisa
Bence Romsics
Slawek Kaplonski
Rodolfo Alonso Hernandez
Lucas Alvares Gomes
XiaoYu Zhu