forked from openstack/neutron
-
Notifications
You must be signed in to change notification settings - Fork 2
Synchronise 2023.1 with upstream #150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
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
A fix for an invalid cherry pick [0] missed updating all the unit tests that had an invalid key. Fix it. [0] https://review.opendev.org/c/openstack/neutron/+/913408/ Related-bug: #2057942 Change-Id: I167067c185b63e7e1b4b3c0821e73315c60ea018
The OVN changed support for NAT rules including a new column and auto discovery logic (which may not work in some cases) [1][2]. If the OVN backend supports this column in the Northbound DB Schema, set gateway port uuid to any floating IP to prevent North/South traffic issues for floating IPs. This patch updates the method for creating FIP NAT rules in OVN backend and updates previously created FIP rules to include the gateway_port reference. This NAT rule update task runs only once during the maintenance task, and if all entries are already configured no action is performed. [1] ovn-org/ovn@15348b7 [2] ovn-org/ovn@2d942be Conflicts: neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/ovsdb/test_maintenance.py (cherry picked from commit 78b5fe2) Closes-Bug: 2035281 Change-Id: I802b6bd8c281cb6dacdee2e9c15285f069d4e04c Signed-off-by: Mohammed Naser <mnaser@vexxhost.com>
This reverts commit b92fc1a. Reason for revert: The original change was made as a “cheap win” to optimize the number of queries the neutron server makes during testing. This did improve the number of queries made but introduced regression in real world deployments where some customers(through automation) would define hundreds of tags per port across a large deployment. I am proposing to revert this change in favor of the old “subquery” relation in order to fix this regression. In addition, I filed the Related-Bug #2069061 to investigate using `selectin` as the more appropriate long term solution. Change-Id: I437ab71f01483bb8adea96757a6d7dd6253df182 Closes-bug: #2068761 Related-Bug: #2069061
When a virtual port is moved from one port to another port the PortBindingUpdateVirtualPortsEvent event would only update the binding host id in the neutron database, while it is also usefull to keep the information in the OVN database up to date with the host information Other plugins that connect to the OVN database can then also rely on the information stored in the OVN DB's Closes-Bug: #2038413 Change-Id: I59c6c4b2c8b023b9c9c3bab1741d957fa1f738fc (cherry picked from commit e68a920)
As mentioned in change [1], the condition should be a `is None` as per inline comment. [1] https://review.opendev.org/c/openstack/neutron/+/896883 (NOTE: This patch retrieves a test that was skipped in a previous backport.) Related-Bug: #2038413 Change-Id: I3666cf0509747863ca2a416c8bfc065582573734 (cherry picked from commit 170d99f)
This patch adds bump revision after updating the hostname of a virtual port (more specifically its associated port). This way there is no misalignment between the revision number of Neutron DB and OVN DB. It also avoids the unnecessary execution of the maintenance task to simply match the revision_number. Closes-Bug: #2069046 Change-Id: I2734984f10341ab97ebbdee11389d214bb1150f3 (cherry picked from commit f210a90)
…model"" into stable/2023.1
If enable explicitly_egress_direct=True and set port as no security group and port_security=False, the ingress flood will reappear. The pipleline is: Ingress table_0 -> table_60 -> NORMAL -> VM Egress table_0 -> ... -> table_94 -> output Because ingress final action is normal, the br-int will learn the source MAC, but egress final action is output. So VM's mac will never be learnt by the br-int. Then ingress flood comes again. This patch adds a default direct flow to table 94 during the openflow security group init and explicitly_egress_direct=True, then the pipleline will be: Ingress table_0 -> table_60 -> table_94 -> output VM Egress table_0 -> ... -> table_94 -> output And this patch adds the flows coming from patch port which will match local vlan then go to table 94 do the same direct actions. Above flood issue will be addressed by these flows. Closes-Bug: #2051351 Change-Id: Ia61784174ee610b338f26660b2954330abc131a1 (cherry picked from commit d6f56c5) (cherry picked from commit f94f8b6) (cherry picked from commit fc7fa9c) Conflict with 02b12b0 in neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py
…tsEvent" into stable/2023.1
markgoddard
approved these changes
Jun 17, 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.