This new extension adds a new parameter to the NUMA affinity policy
list: "socket". The "socket" NUMA affinity policy has been supported
in Nova since [1].
[1]https://review.opendev.org/c/openstack/nova/+/773792
Closes-Bug: #2052786
Change-Id: Iad2d4c461a2aceef6ed2d5e622cce38362d79687
Since [1] was merged, user defined flavor routers with the HA
attribute set to False cannot be created. This change fixes
it.
Closes-Bug: #2057983
[1] https://review.opendev.org/c/openstack/neutron/+/910889
Change-Id: Ic72979cfe535c1bb8cba77fb82a380c167509060
When handling the deletion of extra routes we need to handle the case
that the route is already deleted by another call in the time we have
fetched the extra routes and try to delete it. This is a classic race
condition when two calls try to update the routes of a router at the
same time. The default MariaDB/MySQL transaction isolation level does
not suffice to prevent this scenario. Directly deleting the route
without fetching it solves this problem.
Change-Id: Ie8238310569eb7c1c53296195800bef5c9cb92a3
Closes-Bug: #2057698
The "ha" API flag is now enabled for the OVN routers. Because of the
current implementation, this flag must be always "True". When a new
router is created, this flag is always set. If an OVN router is
explicitly created or updated with "--no-ha" (ha=False), the server
will raise an InvalidInput exception.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911081
Closes-Bug: #2020823
Change-Id: I60ff33680dd5397a226a9051d51bfb0701f862b5
Since [1], we introduced a way to skip the load of the OVO synthetic
fields depending on the resource fields retrieved. In the case of the
security groups (SG), the SG rules are child objects to the SGs. The SG
rules are retrieved when a SG OVO is created.
The improvement done in [1] is to make the SG rules load dynamically,
that means using the load mode "lazy='dynamic'". That will issue a SQL
query only if the SG rules are read; if not, the query is never issued.
However since [2] (and this is previous to the [1] optimization), we
always add the field "shared" to the filters and thus to the fields to
retrieve, because it is a policy required field. Because "shared" is a
synthetic field [3], that will force the SG "synthetic_fields" load and
the retrieval of the SG rules always. This is undoing any performance
improvement.
This patch is changing the loading method to "joined"; that will request
the SG rules in the same SQL query, instead of issuing separate queries
for the SG rules. Until a method to load the SG "shared" field,
independently of the synthetic OVO fields is implemented, this change
will improve the SG retrieval performance. In a testing environment
with around 5500K SG and 4 rules (default ones) per SG:
* lazy='dynamic': 38 seconds
* lazy='select': 20 seconds
* lazy='joined': 12 seconds
[1]https://review.opendev.org/q/topic:%22bug/1810563%22
[2]https://review.opendev.org/c/openstack/neutron/+/328313
[3]b85b19e384/neutron/objects/rbac_db.py (L349)
Related-Bug: #2052419
Change-Id: I300464472f2348d148f2a3ddac384c883d9d815b
Update hacking to a more recent version, along with
flake8-import-order.
Remove N347 (import mock library) check as that is the
default with later hacking versions.
Update the builtins override of '_' to be the neutron.i18n
version due to the code triggering a false positive. This
is done in a couple of other projects as well.
Fix a number of new warnings it found.
Added some ignore directives for new whitespace issues
found in the test tree, can fix later.
TrivialFix
Change-Id: I5923255af86cf1fa11ab8e3b03bb9efac7dd7b58
All of these exceptions and constants have been in
neutron-lib for a while, start using them.
While looking for other things to consume found an old
neutron-lib TODO that did not apply anymore, so removed.
TrivialFix
Change-Id: I9431075a50ba05be872db422125e6af6266ccb99
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
When a router interface is created, the corresponding subnet gateway IP
is tested first [1]. If the subnet has no gateway IP, the router
interface cannot be created. This IP will be assigned to this port.
The Neutron API also prevents from modifying the subnet gateway IP
if assigned to a router interface [2]. However the API is not
preventing the subnet gateway IP deletion. This patch is adding
this check.
This patch is being tested in the neutron-tempest-plugin [3].
[1]de58c1b995/neutron/db/l3_db.py (L902-L904)
[2]de58c1b995/neutron/db/db_base_plugin_v2.py (L715)
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
Closes-Bug: #2036423
Change-Id: I4c7b399a3a052749abdb88fb50be628ee91b63a0
This is a follow-up patch to handle a missing comment. The except
branch should never catch a ``AttributeError`` exception, only a
``KeyError`` if that is missing in the ``data`` dictionary.
Related-Bug: #2013228
Change-Id: I6a3249649dde58e666048a613640338ea8af7b36
Do not allow the subnet cidr of :: to be used when
creating a subnet, except in the case IPv6 prefix
delegation has been specified in the request.
Closes-bug: #2028159
Change-Id: I480e9a117513996f3c070acd4ba39c2b9fe9c0f1
This method populates the SG rules in a dictionary. Each SG rule
inherits the "stateful" value of the SG. Prior to this patch, each
SG rule was isuing a database call to retrieve the SG register.
In this patch, the SG "stateful" retrieval is done in one database
query for all SG. That improves the performance of this method
reducing the database access to only one single call.
This improvement, as commented in the LP bug, affects to
ML2/LinuxBridge. ML2/OVS agent uses a cached RPC implementation
that not requires to perform any RPC call/database query.
Closes-Bug: #2045950
Change-Id: Iafd0419a1d1eeb25d5589edc2570ebf287450957
It's not necessary to get all port informations for the
floating IP port DB query. And the device_id and
device_owner is unique for the DB query.
Change-Id: If7ed1d1b1d9798c0df676bc8c452fb0fa9e288d1
[1] changed FIP OvO for QoS update, but it seems that
it introduced a regression when FIP is updated without
QoS policy in the request.
[1]: https://review.opendev.org/c/833667
Closes-Bug: #2041609
Change-Id: I254e1625c1a157e562df22ae2fd5c6e28971f812
When creating a subnet using a subnetpool, we were
failing to validate all the passed API arguments in
the dictionary, leading to a case where you could
specify an invalid DNS nameserver. For example,
using an IPv4 nameserver on an IPv6 subnet. This
could cause daemons the l3-agent starts, like radvd,
to fail to start correctly, leading to a loss of
connectivity.
Specifying a subnet by cidr without a subnetpool
did already correctly fail with an IP version
mismatch error, this is just an edge case that
was never tested.
Since _validate_subnet() was called in so many places
it was moved to a common location and is only not
called for IPv6 prefix-delegation subnets.
Closes-bug: #2036877
Change-Id: I6302e9a373cf93e706cec10f87c3beaf632a0391
The apidef allows for updating the `enable_default_route_bfd` and
`enable_default_route_ecmp` router extra attributes, however the
extension does currently not implement a receiver for it.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Ic7b73fb58fd2e3a6c689511038c0681cf99a1cfb
The default value for 'enable_default_route_bfd' and
'enable_default_route_ecmp' is configurable.
Ensure the default comes from configuration if a request to create
router does not contain a value for these attributes.
Partial-Bug: #2002687
Change-Id: I581f4c5e5cfa275f8a6f0adec405f205e877ac55
When the `update_external_gateways` API endpoint is called with
a set of IPs different than the ones currently existing for a
router, the current code will raise an `UnableToMatchGateways`
exception.
We fix this by adding a optional `no_match_fixed_ip_fatal`
argument to `_match_requested_gateway_ports` and by returning
the requested port info in `nonexistent_port_info`.
After this, a new port will be created as expected. The now
surplus port is also identified for removal in the
`ports_to_remove` set.
However, the list comprehension used to filter the removal request
is based on input from user, and not the actual list of external
gateway ports attached to the router, leading to a failure to
remove the unwanted port.
Replace the `ports_to_remove` set with a list comprehension of
actual router gw ports for input to the `_remove_external_gateways`
method.
This change also avoids unneccesary calls to
`_remove_external_gateways` as all ports for removal are passed in
at once instead of one at a time in iteration.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I5dccb7b9ba3a432e32baf37d30af02c6a393c9b1
If the port being removed is not the first one, the current code
will raise a KeyError.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I948ff385e8a6aa7ecccce26b04a9d67affaede2c
During testing we found several places where the current code is
unable to find GW ports due to using an unpriviliged context to
list them.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I253f8caf1e1c52244cee22a22ee1773740165d55
This is the list of tables removed from the Neutron database:
* neutron.db.migration.alembic_migrations.external.REPO_CISCO_TABLES
* neutron.db.migration.alembic_migrations.external.REPO_VMWARE_TABLES
* neutron.db.migration.alembic_migrations.external.REPO_BROCADE_TABLES
* neutron.db.migration.alembic_migrations.external.REPO_NUAGE_TABLES
* other tables: "cisco_csr_identifier_map"
Closes-Bug: #2038555
Change-Id: Ia39f759dd7567970b00856e334786e4df74966cf
The policy rule ``shared_security_group`` allows to create new policy
rules checking if a security group rule belongs or not to the project
default security group.
By default the behaviour has not changed. If an administrator wants
to prevent a non-privileged user from creating or deleting rules in the
default security group, the ``create_security_group_rule`` and
``delete_security_group_rule`` can be overriden. An example is provided
in the unit tests.
Closes-Bug: #2019960
Change-Id: I6c90b61df0e726ef07f177801069baf30c49de67
The method ``delete_security_group_rule`` is publishing the
BEFORE_DELETE event before starting the security group rule deletion.
This event is published using a wrap method called
``SecurityGroupDbMixin._registry_publish``. This method is capturing
any ``CallbackFailure`` exception and raising a
``SecurityGroupRuleInUse`` one. That makes no sense because:
* We are hidding the real cause of the callback failure.
* The BEFORE_DELETE is not checking that the security group rule is
being used (NOTE 1).
* If any new implementation makes this check, the corresponding callback
should return explicitly this exception.
The method ``_create_security_group_rule`` is publishing the
BEFORE_CREATE event before starting the security group rule creation.
The same argument applies here: the callback manager should return the
exception raise by the callback method (NOTE 2).
In a follow-up patch, this events will be captured to check the
permissions related to the user creating or deleting the security group
rule. In case of error, it will be needed to raise a ``NotAuthorized``
derived exception, instead of a ``InUse`` one.
NOTE 1: this is the current use of BEFORE_DELETE event in the
OpenStack repository:
* [2] Omni project had no activity for the last 4 years.
* [3] networking-arista: the method ``run_cmds_on_all_switches``, that
calls ``run_openstack_sg_cmds``, returns its own exceptions.
* [4] networking-opencontrail: same justification.
* [5] The ML2/OVN mechanism driver, that will raise an exception if the
OVN ACL deletion doesn't succeed.
NOTE 2: this is the current use of BEFORE_DELETE event in the
OpenStack repository:
* [2] Omni project had no activity for the last 4 years.
[1]https://codesearch.openstack.org/?q=%5C.SECURITY_GROUP_RULE&i=nope&literal=nope&files=&excludeFiles=&repos=
[2]https://opendev.org/x/omni/src/branch/master/neutron/neutron/plugins/ml2/drivers/aws/callbacks.py
[3]https://opendev.org/x/networking-arista/src/branch/master/networking_arista/ml2/security_groups/arista_security_groups.py
[4]https://opendev.org/x/networking-opencontrail/src/branch/master/networking_opencontrail/ml2/opencontrail_sg_callback.py
[5]https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py
Partial-Bug: #2019960
Change-Id: I8d5f5392fb7a6ab9b20e9222c143f4e67c925cae
This new extension adds a new synthetic field, "belongs_to_default_sg",
to the security group rule OVO. This read only boolean field determines
if the security group rule belongs to a default security group or not.
This new field will be used in a new set of policy rules. By default,
these new rules will allow to create and delete security group rules
into the default security group of a project only to the admin user
NOTE: the follow-up patch will introduce the policy rules check,
during the creation/deletion operations, of the
"belongs_to_default_sg" field and the user executing this action.
Partial-Bug: #2019960
Change-Id: I0b3ded52e1ff8160c5804c59635c0fd34ce9995b
For some reason, kilo_initial.py is triggering this warning,
so fix it by using comments instead of a docstring.
Also updated the template to use comments as well, so any
migrations created in the future use them, even though
none seem to be causing a similar warning right now.
Closes-bug: #2036763
Change-Id: I63b7ac83fdd3ebc6251979f1376daf2105489fdc
Default SG rules created as template in the Neutron DB are now used to
create security group rules for each new default and non-default SG
created in Neutron.
Closes-bug: #1983053
Change-Id: Iaf27deb955c3844409fcd36239511478e9607a82
This patch introduces a maintenance task that runs once a day and is
responsible for cleaning up Hash Ring nodes that haven't been updated in
5 days or more.
Change-Id: Ibed9e0d77500570c3d0f9f39bfe40cb9239d0d7a
Closes-Bug: #2033281
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
When a HA router is created and the HA is not yet, before creating
the router, the Neutron server creates the HA network and the
corresponding subnet.
The HA network cannot be duplicated (see previous patches related to
this bug). But the subnet, that is created in another database
transaction, cannot be present when the router creation call tries
to create the HA port.
This patch adds a HA subnet check before creating the router and the
HA port. Even if the subnet check fails and the worker tries to
create this subnet, if the process fails with ``InvalidInput``, that
means other worker created the subnet before and the current one
fails because tries to create the same subnet with the same CIDR.
In this case, we dismiss the exception and continue with the router
creation.
Closes-Bug: #2016198
Change-Id: I82225fcc6248bb0fd68959ceb1daabff423d81ff
This patch implements the new network HA boolean field API extension.
This field is an input only parameter for POST operations (creation).
By default is "False". When enabled, the Neutron server will create
a ``ha_router_networks`` register in the same transaction of the
network creation.
If by any circumstance (a race condition, for example), another
``ha_router_networks`` exists in the same project, a
``DBDuplicateEntry`` exception will be raised and the transaction
will be rolled back.
Partial-Bug: #2016198
Change-Id: Ie42c13ecbe4abcad9229b71f6942e393fd0f2e4e
Raise an error when deleting/changing the fixed IP
which is linked to a floating IP.
Closes-Bug: #1999209
Change-Id: I83a5b6c30d54435426f75f4cd1f80bf41822eec5