Synchronise 2023.1 with upstream #165
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
VIF details
In this 2023.1 branch only version the retrieval of the bridge_name
is done by checking either Chassis or Chassis_Private table. The ovn
metadata agent uses already present `has_chassis_private` attribute
to detect Chassis or Chassis_Private.
The mech_driver checks `agent_chassis_table` name to retrieve from
either Chassis_Private or Chassis
Same as in ML2/OVS, the ML2/OVN mechanism driver adds to the port
VIF details dictionary the OVS bridge the port is connected to
and the integration bridge datapath type.
Conflicts:
neutron/common/_constants.py
neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py
neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
Closes-Bug: #2045889
(cherry picked from commit baaf240)
Change-Id: Id299eb7faf540b41836513bfb566157c8996a355
Although a wait_until_true() was added to this test, it
still occasionally fails. From the debug it looks like
the very next read of interfaces shows the one we were
waiting for was now present:
AssertionError: MacVTap address: 4e:0f:75:b8:c8:c2,
read devices: {'4e:0f:75:b8:c8:c2'}
Device ens3, MAC: fa:16:3e:14:44:a1
Device macvtap7b63baf3, MAC: 4e:0f:75:b8:c8:c2 ...
Increase the timeout to 10 seconds to see if it helps
the test become more stable.
Change-Id: Ie66163c0e8459c1e90ae3af375469f9996f0801c
Related-bug: #2012510
(cherry picked from commit 8cd949f)
https://review.opendev.org/c/openstack/neutron/+/867359 inadvertently dropped a return when binding:profile was missing, making it possible to hit a KeyError when trying to access port["binding:profile"]. This was seen in the Maintenance thread after adding a port. Fixes: b6750fb Closes-Bug: #2071822 Change-Id: I232daa2905904d464ddf84e66e857f8b1f08e941 (cherry picked from commit e5a8829)
To solve a performance issue when using network rbacs with thousands of entries in the subnets, networks, and networks rbacs tables, it's necessary to change the eager loader strategy to not create and process a "cartesian" product of thousands of unnecessary combinatios for the purpose of the relationship included between rbac rules and subnetpool database model. We don't need a many-to-many relationship here. So, we can use the selectin eager loading to make this relationship one-to-many and create the model with only the necessary steps, without exploding into a thousands of rows caused by the "left outer join" cascade. The "total" queries from this process would be divided into a series of smaller queries with much better performance, and the resulting huge select query will be resolved much faster without joined cascade, representing significant performance gains. Closes-bug: #2071374 Change-Id: I2e4fa0ffd2ad091ab6928bdf0d440b082c37def2 (cherry picked from commit 46edf25)
In [1], a method to process the DHCP events in the correct order was implemented. That method checks the port events in order to match the "fixed_ips" field. That implies the Neutron server provides this information in the port event, sent via RPC. However in [2], the "fixed_ips" information was removed from the ``DhcpAgentNotifyAPI._after_router_interface_deleted``, causing a periodic error in the ``DHCPResourceUpdate.__lt__`` method, as reported in the LP bug. This patch is restoring this field in the RPC message. [1]https://review.opendev.org/c/openstack/neutron/+/773160 [2]https://review.opendev.org/c/openstack/neutron/+/639814 Closes-Bug: #2071426 Change-Id: If1362b9b91794e74e8cf6bb233e661fba9fb3b26 (cherry picked from commit b0081ac)
If the DB connection is not stopped at the defined timeout (10 seconds), the clean-up process will continue. Closes-Bug: #2034589 Change-Id: I6c3b4da49364c3fed86053515e79121acac078d6 (cherry picked from commit b40c728)
…y" into stable/2023.1
Currently when sriov agent is enabled and migrating a non-sriov instance, non-sriov port status is frequently set to BUILD instead of ACTIVE. This is because the 'binding_activate' function in sriov-nic-agent sets it BUILD with get_device_details_from_port_id(as it calls _get_new_status). This patch checks network_ports in binding_activate and skip binding port if it is not sriov port Closes-Bug: #2072154 Change-Id: I2d7702e17c75c96ca2f29749dccab77cb2f4bcf4 (cherry picked from commit a311606)
…e port VIF details" into stable/2023.1
github-actions
bot
added
automated
markgoddard
approved these changes
Jul 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains a snapshot of 2023.1 from upstream stable/2023.1.