net, evpn: refactor helpers for independent endpoint deployment#5248
net, evpn: refactor helpers for independent endpoint deployment#5248servolkov wants to merge 1 commit into
Conversation
Separate shared EVPN infrastructure (bridge VLAN/VNI mappings, L3 VRF) from per-endpoint setup so multiple endpoints can coexist independently. - Move VLAN/VNI mappings into deploy_evpn_bridge (shared, created once) - Extract deploy_evpn_l3_vrf/teardown_evpn_l3_vrf from L3 endpoint - Use uuid-suffixed netns/veth names for endpoint isolation - Teardown functions take EvpnEndpoint instead of raw pod/vni args - Update test_source_provider_migration to use new signatures Signed-off-by: Sergei Volkov <sevolkov@redhat.com> Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughRefactors EVPN endpoint deployment in ChangesEVPN endpoint lifecycle refactor
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsLinked repositories: Your configuration references 1 linked repositories, but your current plan allows 0. Analyzed ``, skipped Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Report bugs in Issues Welcome! 🎉This pull request will be automatically processed with the following features: 🔄 Automatic Actions
📋 Available CommandsPR Status Management
Review & Approval
Testing & Validation
Container Operations
Cherry-pick Operations
Branch Management
Label Management
✅ Merge RequirementsThis PR will be automatically approved when the following conditions are met:
📊 Review ProcessApprovers and ReviewersApprovers:
Reviewers:
Available Labels
AI Features
Security Checks
💡 Tips
For more information, please refer to the project documentation or contact the maintainers. |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/network/bgp/evpn/test_evpn_connectivity.py (1)
215-231:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHIGH:
new_l2_endpointis created but never torn downAfter switching to endpoint-object teardown, this test removes the old endpoint but does not clean the newly deployed
new_l2_endpoint. That leaves endpoint lifecycle asymmetric and risks stale netns/veth artifacts in the FRR pod.Suggested fix
new_l2_endpoint = deploy_evpn_l2_endpoint( pod=frr_external_pod.pod, endpoint_ips=[_L2_ENDPOINT_IPV4, _L2_ENDPOINT_IPV6], ) - - assert_evpn_workloads_connectivity( - target_vm=vm_evpn_target, - ref_vm=vm_source_provider, - l2_endpoint=new_l2_endpoint, - l3_endpoint=external_l3_endpoint, - subtests=subtests, - ) + try: + assert_evpn_workloads_connectivity( + target_vm=vm_evpn_target, + ref_vm=vm_source_provider, + l2_endpoint=new_l2_endpoint, + l3_endpoint=external_l3_endpoint, + subtests=subtests, + ) + finally: + teardown_evpn_l2_endpoint(endpoint=new_l2_endpoint)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/network/bgp/evpn/test_evpn_connectivity.py` around lines 215 - 231, The test creates new_l2_endpoint by calling deploy_evpn_l2_endpoint() but never cleans it up, leaving the endpoint lifecycle asymmetric and risking stale artifacts in the FRR pod. After the assert_evpn_workloads_connectivity() call completes, add a teardown_evpn_l2_endpoint(endpoint=new_l2_endpoint) call to properly clean up the newly deployed endpoint and maintain symmetric resource management consistent with how external_l2_endpoint is torn down at the beginning.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/network/bgp/evpn/libevpn.py`:
- Around line 214-218: The UUID suffix generation using uuid.uuid4().hex[:3]
only provides 4096 unique combinations. To improve collision resistance for
potential higher parallelism or longer-lived namespaces in future test
scenarios, extend the hex suffix length from 3 characters to 4 or 5 characters
in the suffix assignment. This change requires modifying only the string slicing
operation where the suffix is generated (uuid.uuid4().hex[:3]) to use a longer
substring, which will then be propagated to all the dependent variables like
netns, veth_pod, and veth_ep that use this suffix.
---
Outside diff comments:
In `@tests/network/bgp/evpn/test_evpn_connectivity.py`:
- Around line 215-231: The test creates new_l2_endpoint by calling
deploy_evpn_l2_endpoint() but never cleans it up, leaving the endpoint lifecycle
asymmetric and risking stale artifacts in the FRR pod. After the
assert_evpn_workloads_connectivity() call completes, add a
teardown_evpn_l2_endpoint(endpoint=new_l2_endpoint) call to properly clean up
the newly deployed endpoint and maintain symmetric resource management
consistent with how external_l2_endpoint is torn down at the beginning.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 817e2f6a-73c7-454e-a8cc-4d135427ab67
📒 Files selected for processing (3)
tests/network/bgp/evpn/conftest.pytests/network/bgp/evpn/libevpn.pytests/network/bgp/evpn/test_evpn_connectivity.py
What this PR does / why we need it:
Separate shared EVPN infrastructure (bridge VLAN/VNI mappings, L3 VRF) from per-endpoint setup so multiple endpoints can coexist independently.
Which issue(s) this PR fixes:
Special notes for reviewer:
jira-ticket:
NONE
Summary by CodeRabbit
Release Notes