According to the neutron API-REF [1] port's "binding:profile" field is
intended to be used for the "machine-machine communication for compute
services like Nova, Ironic or Zun to pass information to a Neutron
back-end." so it should be by allowed only for the users with the
SERVICE role granted, not even for ADMIN.
This patch updates that policies to be available only for SERVICE role
when new, secure RBAC policies are enabled.
Additionally this patch updates some policies for create, update and get
port APIs to make them all work in the same way and allow them for the
SERVICE users too.
Finally this new policy for create/update_port:binding:profile have to
be overwritten in the fullstack tests to be allowed also for admin user.
It is done by adding custom policy file for the fullstack tests only.
[1] https://docs.openstack.org/api-ref/network/v2/index.html#create-port
Closes-Bug: #2052937
Change-Id: I5c0094ff21439fe8977cfc623789a09067e6a895
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
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
The optional network argument was deprecated in
update_port_status() in Pike. Let's remove it as there
are are only in-tree callers passing it anymore.
TrivialFix
Change-Id: Iab8d3dada2e147da009e195700e64b072e5bfabb
The vnic type should not be changed once the port is bound since it's
related to the actual port binding. The patch validates the port update
operation and fails the update if the vnic type is attempted to be
changed on a bound port.
Closes-bug: #2033090
Change-Id: I5cb79d9da96ba41a7787083c81f522c328fae049
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
During the port bulk creation, if an IPAM allocation fails (for
example, if the IP address is outside of the subnet CIDR), the
other IPAM allocations already created are deleted before raising
the exception.
Closes-Bug: #2039550
Change-Id: I7fd6e38016d099c03f80874bfa1fb8bdaff8bd2c
When we use the ovn driver, the security group is implemented
by the ACL of ovn. There is no need to send rpc messages.
Closes-Bug: #2007327
Change-Id: I4b486c910ed298633ac6f60fd93f695c6c3bfef2
As part of the Secure RBAC community goal, we should switch options
"enforce_new_defaults" and "enforce_scope" to be True by default.
It will be still possible to fallback to old policy rules by configuring
those config options to False in Neutron config.
Change-Id: I09c0026ccf87e6c0bb1fa59165c03dc508fba6fa
Those modules needs to ensure that common config options
are registered.
Otherwise it can't be successfully run without other tests as it was
then failing due to unregistered config option.
Trivial-fix
Change-Id: Ifa348218229b6be64bb7403d933df82f03afafdf
It was somehow missed initially when we wrote new Secure RBAC policies
but network owner should be able to see all ports created on the
network.
Additionally this patch adds mock of the neutron.policy.check function
in TestMl2DbOperationBounds class as this class is expected to check
DbOperators made by ML2 plugin while listing ports so there's no need to
include policy checks there too.
Change-Id: I2560edb915f7393fcda50dd4a37a1d366bd0ce59
Bulk port create without mac address fails as when Neutron calls
oslo_utils.netutils.get_ipv6_addr_by_EUI64, as the mac field of the port
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f4755d8fd1af3b98e281c3109420f6
For multi segments support we have update the unique contraint so
`segment_index` will be part of it.
Related-Bug: #1791233
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic564131dcd7525fc5f24c3282688e3584cd2e2e0
The port provisioning method ``Ml2Plugin._port_provisioned`` creates
an active wait to provision a port if the port is unbound since [1].
But this active wait should consider only VM ports in the case of
live migration, as described in the LP bug [2]. This wait should
not consider auxiliary Neutron ports or baremetal ports (we don't
live-migrate then).
[1]https://review.opendev.org/c/openstack/neutron/+/855257
[2]https://bugs.launchpad.net/neutron/+bug/1988199
Closes-Bug: #1991092
Change-Id: Ic8891e2deef4bb5e72cf7d7f37b043e936adbc00
In ML2/OVN, during a live-migration process, it could
happend that the port provisioning event is received before
the port binding has been updated. That means the port has
been created in the destination host and the event received
(this event will remove any pending provisioning block). But
the Nova port binding request has not arrived yet, updating
the port binding registers. Because the port is considered
"not bound" (yet), the port provisioning doesn't set the port
status to ACTIVE.
This patch creates an active wait during the port provisioning
event method. If the port binding is still "unbound", the method
retries the port retrieval several times, giving some time to the
port binding request from Nova to arrive.
Closes-Bug: #1988199
Change-Id: I50091c84e67c172c94ce9140f23235421599185c
Since [1] (in oslo.db>9.1.0), the ``Session.autocommit`` member
is removed and should not be considered. This patch removes this
dependency while keeping backwards compatibility. This code will
be removed in future releases.
Due to the neutron-lib dependency, this patch bumps the needed
library version to 3.1.0.
[1]https://review.opendev.org/c/openstack/oslo.db/+/804775
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/851193
Closes-Bug: #1982818
Change-Id: Ibfcf9d5f6cd805f2d64fcd88049e2b43fedc3497
The ML2/OVN driver wasn't handling updates to the segmentation ID for a
given network. This patch fixes this problem.
This patch extends the _update_segmentation_id() method to check on
drivers which does not inherits from AgentMechanismDriverBase, which
is the case of OVN (which inherits from MechanismDriver). A new method
is now called for those drivers to get a list of supported VIF types,
called get_supported_vif_types().
Closes-Bug: #1944708
Change-Id: Ibe08bfbc2efc55b9d628cdd0605941b7486186b6
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Removed unneeded database context in
``_create_port_security_group_binding``. This method is called always
from inside an active database transaction, when the port is udpated
or created.
The retry context only makes sense when a method is called outside
an active database transaction. It doesn't retry the command if the
context passed has an active transaction.
Trivial-Fix
Change-Id: I8f84c1bce0d1ce2538789e3511fd8f7b64fcd41a
Include original and modified network when notifying mechanism drivers in PRECOMMIT event. PRECOMMIT_CREATE modified network includes new segment, while original does not. Exact opposite for PRECOMMIT_DELETE
Closes-Bug: #1967742
Change-Id: I364fc7981458374ed25eb8837d1ed3afff046b95
Today Nova updates the mac_address of a direct-physical port to reflect
the MAC address of the physical device the port is bound to. But this
can only be done before the port is bound. However during migration Nova
is not able to update the MAC when the port is bound to a different
physical device on the destination host.
This patch extends port binding logic for direct-physical ports to allow
providing the MAC address of the physical device via the binding profile.
If it is provided then Neutron overwrites the value of the mac_address
field of the port with the value from the active binding profile.
Also when the port is being unbound or the MAC address is removed from
the active binding porfile then neutron resets the mac_address field of
port to a generated MAC to avoid duplicated MAC issues when another port
is being bound to the same physical device.
The shim API extension for this change is being proposed in
I54b4c85ffc4856fba7ad5e9e29f77f74815e1275 in neutron-lib.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/831935
Closes-Bug: #1942329
Change-Id: Ib0638f5db69cb92daf6932890cb89e83cf84f295
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+-----+---------------+------------+---------------------------+
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+-----+---------------+------------+---------------------------+
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+-----+---------------+------------+---------------------------+
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+-----+---------------+------------+---------------------------+
Closes-Bug: #1954763
Change-Id: I8877c658446fed155130add6f1c69f2772113c27
Config option allow_overlapping_ips is deprecated to removal now and
will be removed in the Z cycle.
Default value for that option is now set to True as this is supported by
IPAM module in Neutron.
Related-Bug: #1942294
Change-Id: I17bf5e4483025e9cc4ee04dd3e7c925f7bddc3db
When two segments are concurrently created this could have resulted in
both threads creating a segment, thus resulting in two segments with
different segmentation ids. To prevent this we now introduce a new
unique constraint onto the networksegments table, which requires
(network_id, network_type, physical_network) to be unique, which allows
only a single segment with a single segmentation id to exist per
combination of these three values.
With the constraint in place a DB error will be thrown, which will cause
allocate_dynamic_segment() to be executed again and this time it will
find the already existing segment. To make sure that no additional DB
objects are created when segment creation failed we need to put all of
the allocation code into a DB transaction.
Change-Id: I407ae88d69ed971bf8d9a9b79120366f33bb56fd
Closes-Bug: #1791233
The goal of [1] is to, in case of failing when removing the quota
reservation, continue the operation. Any expired reservation will
be removed automatically in any driver.
If the DB transaction fails, it should affect only to the reservation
trying to be deleted. This is why this patch isolates the
"remove_reservation" method and guarantees it is called outside an
active DB session. That guarantees, in case of failure, no other DB
operation will be affected.
This patch also partially reverts [2] but still checks the security
group rule quota when a new security group is created. Instead of
creating and releasing a quota reservation for the security group
rules created, now only the available quota limit is checked before
creating them. That won't prevent another operation to create security
group rules in parallel, exceeding the available quota. However, this
is not even guaranteed with the current quota driver.
[1]https://review.opendev.org/c/openstack/neutron/+/805031
[2]https://review.opendev.org/c/openstack/neutron/+/701565
Closes-Bug: #1943714
Change-Id: Id73368576a948f78a043d7cf0be16661a65626a9
The method is deprecated since Python 3.2[1] and shows the following
DeprecationWarning.
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
Closes-Bug: #1938103
Change-Id: Iab60f52ffbfb3668e9509ce86e105917c616b8a9
Bulk port creation should honor binding:vnic_type
and binding:profile attributes from request.
Closes-Bug: #1940074
Change-Id: I99d27d568f66c6330f6373843d096c6ee1b4ec54
Provisioning Blocks [1] was introduced to manage composite
object status. Port object is the one Neutron sets provisioning
block during the port processing life cycle. Here is the compute
port (VM's NIC port) processing procedure:
1. nova creates port
2. the 'openvswitch' mechinism driver inserts provisioning block
for this port
3. nova calls related interface to plug the device
4. L2-agent sets the flows (or rules/devices) for the port and
call update_device_list to neutron-server
5. neutron-server try to set port status to ACTIVE
6. neutron-server notify nova that "vif-plugged" success
This works fine for VM with its ports. But for neutron service port,
like router_gateway, router_interface and dhcp, it is unnecessary.
Because there is no dependency among neutron resources. Neutron
just knows that the ports had been set properly. And another thing
is, for most of these internal service port, there is no need of
DHCP, security group or port security.
So for neutron internal service ports, the procesure can be:
1. neutron L3/DHCP/X related service plugin creates port
2. no provisioning_block
3. L3/DHCP/X related agent plug the port
4. L2-agent sets the flows (or rules/devices) for the port and
call update_device_list to neutron-server
5. neutron-server sets port status to ACTIVE directly, then done!
This patch will set neutron *AgentMechanismDrver (including built-in
drivers: linuxbridge, macvtap, sriov, openvswitch) to skip inserting
the provisioning_block for Neutron internal service ports.
[1] https://docs.openstack.org/neutron/latest/contributor/internals/provisioning_blocks.html
Closes-Bug: #1930432
Change-Id: Iaf7788bf0cba19a693cbf456f98e50d7b5de9e41
This patch switches over to callback payloads for PORT
AFTER_DELETE events.
Some shims were removed.
Change-Id: If69e37b84fe1b027777b1d673b3d08a6651a979e
Previously if extension was not supported by one of the mech drivers,
but it wasn't filtered out by next mech driver, it was available finally
in the list.
Now, this patch changes that so if extension is disabled by one of the
drivers it isn't available on the list at all.
This will work better e.g. with discoverability of what is available
e.g. when OVN backend is used by Neutron.
Closes-Bug: #1929676
Change-Id: I6a4ff42f47f7ee90365516d37472c09ac87773e5
Slawek Kaplonski