The OVS Firewall has a singleton class that manages the conjuction IDs
to used in the OF rules. Those conjuntions are used to group rules
related to remote security group IDs.
Now each time the OVS agent is started, the OVS Firewall initial
conjunction ID is calculated based on the present OF rules. This value
and the next one used won't clash with any present rule in the
integration bridge during the initial transient period.
Related-Bug: #1934917
Change-Id: Ie2e4441f766947a2164dec2d1555c7049428903f
This patch switches over to callback payloads for ROUTER
AFTER_CREATE, AFTER_UPDATE and AFTER_DELETE events.
Change-Id: Ie818ffbb1a291faa80501157b46ff6671d5c26ba
This patch changes the get_candidates_for_scheduling() method to also
consider all gateway chassis as potential candidates (limited by
Availability Zones) in case physnet parameter is empty (as for the
segmented networks case).
This patch is a simpler/backportable fix for the segmented networks +
Router AZs use case. In the future we should consider refactoring the
code responsible for scheduling the gateway router ports, a more detailed
explanation of what is happening/needed can be found at LP #1939144.
Change-Id: I8dc5336c6e2acd0b0a2cad0e80eee91280b9f945
Closes-Bug: #1939144
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
With new scopes, when e.g. project admin context is used to ensure
default SG for different tenant, elevated context needs to be used
to make db query. Otherwise default SG will not be found and attempt to
create it in DB may fail with DuplicateDbEntry error.
Closes-Bug: #1938910
Change-Id: Ib884be6aa12bd0d3faf83f3e753f8e7aad503b68
Invalid OFPORT (-1) causes ofctl errors and timeouts if set
it as output in a flow rule.
Closes-Bug: #1938685
Change-Id: Ib8be66c3068309832e08066af4e0b75c30e8163a
This patch switches over to callback payloads for ROUTER
BEFORE_CREATE, PRECOMMIT_CREATE, BEFORE_UPDATE and
PRECOMMIT_DELETE events.
Change-Id: I4a52c773d3f753c918df0986f1d261083156651c
In "test_restart_rpc_on_sighup_multiple_workers", the test needs to
wait until the RPC workers have been properly launched by
``oslo_service.service.ProcessLauncher.launch_service``. Once this
method returns, it is guaranteed that the child worker processes
are running and the signal process handlers are attending the
SIGHUP signal that will reset them.
Closes-Bug: #1938428
Change-Id: I1dc56092d099223accc3aefa8e303310c4f6787e
In order to mitigate the OOM problems in the CI, this patch reduces
the fullstack concurrency to 2. That should reduce the memory
consumption and will avoid those nasty OOM exceptions.
Closes-Bug: #1938455
Change-Id: I4de4b089e615353b7fde82bd54e0abefa244c8ab
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
This parameter, sent by the DHCP agent, is needed to remove the
workaround method "_get_network_lock_id".
The removal of this method will be done in [1] in Y release.
Related-Bug: #1732456
[1]https://review.opendev.org/c/openstack/neutron/+/800967
Change-Id: Ibd7fed33d314e901c69da33f42029f8ea67df98d
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 patch adds new API extension to QoS service plugin
to allow CURD actions for packet rate limit (packet per
second) rule in Neutron server side.
NOTE: This patch will NOT implement the real functionality
in L2/L3 backend to limit the pps.
Co-Authored-By: NANALI <lin203@chinaunicom.cn>
Closes-bug: #1912460
Change-Id: Icc88accb88d9cec40c960c56f032c3c27317b42e
Make sure we pass integer values to ovs when configuring bandwidth
limit. This was likely working properly with Python2, and we may have
missed this when migrating to Python3:
https://www.python.org/dev/peps/pep-0238/
Change-Id: I2f8d974d6644657aea95302d94ca0095d70a7e62
Closes-Bug: #1936839
Co-Authored-By: Tamás Trásy <tamas.trasy@ericsson.com>
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
Rodolfo Alonso Hernandez