MitchDrage opened a new pull request, #14240: URL: https://github.com/apache/cloudstack/pull/14240
### Description Fixes #13966 Deleting a persistent VXLAN network left its bridge and VXLAN interface behind on every host that never ran a VM on it. Two changes were needed: 1. **Management server**: `networkMeetsPersistenceCriteria()` only accepted the `Vlan` broadcast scheme, so `CleanupPersistentNetworkResourceCommand` was never sent for `vxlan://` networks. It now accepts `Vlan` and `Vxlan`. 2. **KVM agent**: `BridgeVifDriver.deleteBr()` always built the VLAN-style bridge name (`br<pif>-<vni>`), while VXLAN bridges are created as `brvx-<vni>`. Once the command was dispatched, the agent still found no bridge and reported success. It now deletes `brvx-<vni>` for VXLAN networks. I've written this PR which #13968 had started on, but didn't fix the KVM side of the issue. L2 persistent VXLAN networks now also get their bridges set up on all hosts at implement time, matching VLAN behaviour. ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) - [ ] Build/CI - [x] Test (unit or integration test code) ### Feature/Enhancement Scale or Bug Severity #### Bug Severity - [ ] BLOCKER - [ ] Critical - [ ] Major - [x] Minor - [ ] Trivial ### How Has This Been Tested? - **Unit tests**: `NetworkOrchestratorTest` covers the persistence criteria for VLAN and VXLAN. I added some more testing to `BridgeVifDriverTest` for VLAN and VXLAN. - **Real bridges**: ran `createVnetBr()` and `deleteBr()` with the real `modifyvxlan.sh`/`modifyvlan.sh` in a privileged container. With the fix, both bridges are removed. Without it, `brvx-5000` and `vxlan5000` remain. - **Simulator**: advanced zone with VXLAN isolation and 4 hosts. Created and deleted a persistent Isolated network and a persistent L2 network. With the fix, `CleanupPersistentNetworkResourceCommand` reaches all 4 hosts for both. Without it, it reaches none. Not yet tested end to end on physical KVM hosts. #### How did you try to break this feature and the system with this change? - Ran the new VXLAN tests against the unmodified code to confirm they fail there. - Confirmed VLAN behaviour is unchanged: the VLAN lifecycle test, the container run and the simulator run all show the same results before and after the change. - Ran the full test suites of both changed modules (`cloud-engine-orchestration`, 157 tests; `cloud-plugin-hypervisor-kvm`, 535 tests). All pass. - Checked that nothing subclasses `NetworkOrchestrator` or `BridgeVifDriver`, since two methods were made `protected` for testing. Co-authored-by: @waterWang -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
