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
Add relevant infrastructure for performing NDR-related data plane tests and actual testing #1076
Merged
Conversation
This file contains 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
As a prerequisite to testing the data plane connectivity with routes advertised by NDR, this change makes the configuration step reuse the existing network config code that is able to do things like plugging an extra interface to be used in bridge-interface-mappings.
A separate service subnet for FIPs is useful in making sure that connectivity based on the advertised routes really works as opposed to relying on directly connected routes to FIPs in the undercloud network subnet used as an external network.
For the NDR data plane testing case those checks cannot be performed from the node that runs Zaza and instead need to be performed from a unit that receives dynamic routes from the BGP speaker. In order to allow for that case an additional argument is introduced.
In order to actually test L3 for advertised routes, a simple ping test is necessary to perform from a unit that receives dynamic routes.
The configure step for the DRAgent tests configures a name for a floating IP to be checked for at the peer side. Since the data plane tests add one as well for an instance, make sure the control plane-only tests rely on the FIP that has a specific name. This can be useful if the tests are run in a different order.
fnordahl
approved these changes
Jun 17, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
The relevant NDR change as a reference: https://review.opendev.org/c/openstack/charm-neutron-dynamic-routing/+/886157 |
Due to the race condition described in LP: #2024481, before adding networks to the speaker we need to wait until it gets scheduled, otherwise it may not advertise some routes that are attempted to be advertised before the speaker is scheduled to a dragent service causing a non-fatal service error.
get_units returns a unit objects the name of which needs to be accessed by using the .name attribute.
fnordahl
approved these changes
Jun 21, 2023
openstack-mirroring
pushed a commit
to openstack/charm-neutron-dynamic-routing
that referenced
this pull request
Jun 21, 2023
The change includes modifications to bundles to set up components necessary to spawn instances and provide actual connectivity to them. It makes the testing more heavy but adds assurances that the data plane works for the routes advertised by the NDR control plane. The bundle changes also fix an issue that got in with the original OVN bundles: manage-neutron-plugin-legacy-mode is set to True and the plugin is determined to be OVS instead of OVN. The control plane for NDR still worked but with a non-functioning ML2/ovs config causing OVN DBs to be empty. Func-Test-PR: openstack-charmers/zaza-openstack-tests#1076 Change-Id: Ie59b942a0800ce8dd979398f41ed2138472481f1
openstack-mirroring
pushed a commit
to openstack/openstack
that referenced
this pull request
Jun 21, 2023
* Update charm-neutron-dynamic-routing from branch 'master' to 32e0a1fbdf7edd60d71fed7ec1822f3a912b0bab - Add data plane testing for NDR routes The change includes modifications to bundles to set up components necessary to spawn instances and provide actual connectivity to them. It makes the testing more heavy but adds assurances that the data plane works for the routes advertised by the NDR control plane. The bundle changes also fix an issue that got in with the original OVN bundles: manage-neutron-plugin-legacy-mode is set to True and the plugin is determined to be OVS instead of OVN. The control plane for NDR still worked but with a non-functioning ML2/ovs config causing OVN DBs to be empty. Func-Test-PR: openstack-charmers/zaza-openstack-tests#1076 Change-Id: Ie59b942a0800ce8dd979398f41ed2138472481f1
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.
There are several relevant changes to actually make that work.
NDR change: https://review.opendev.org/c/openstack/charm-neutron-dynamic-routing/+/886157