CrossProject:NetVirt VPNService Migration
The VPNService project will migrate some code out to NetVirt and Genius. Because NetVirt and VPNService have some overlap in functionality we will adopt the VPNService code as the new NetVirt.
- Use the existing VPN Services “NetVirt” Code as the basis for the NetVirt re-architecture.
- Move VPN Services “NetVirt” code to the netvirt repo.
- Both teams work on a common code base.
- Use new NetVirt for both VPN Services and existing NetVirt use cases.
- BGP-VPN specific code stays in the VPN Services project.
- Close Feature gaps between VPN Services and existing NetVirt
- Use new NetVirt for new feature development.
- Continue to support existing NetVirt for some limited time TBD.
Phase 1- modules migrated from VPN service to Netvirt
- neutronvpn - An intermediate module that listens to NN DCNs, and instantiates the data in Netvirt as needed
- dhcpservice - Controller based DHCP service
- elanmanager - L2 service
- vpnmanager - Integrated L3
- natservice - Controller assisted SNAT service using non-conntrack flows
- bgpmanager - Module interacting with external BGP protocol engine
- model-bgp - Assist module for BGP
- fibmanager - Module for managing L3 FIB entries in the switches
Phase 2 - migration to use of GENIUS modules
- arputil - ARP pkt generation utility
- interfacemgr - Common logical port abstraction for services
- itm - Transport management entity
- lockmanager - internal locking mechanism for accessing shared resources
- alivenessmonitor - controller driven entity monitoring entity, currently supports ARP and LLDP
- idmanager - Persistent resource manager, used for dataplane resources by services
- mdsalutil - MD-SAL access common utilities
- There is some vpn, quagga, bgp code that needs to remain to fill out the vpnservice project's scope.
- It was easier to move all the code initially and get it to build and run and then move the vpn, quagga, bgp control back to vpnservice.
- Also related were some core functions in vpnservice that we wanted to expose for other consumers. That is the Genius project. netvirt, vpnservice and sfc would use them.
- The new netvirt will have more functionality compared to the old netvirt, so it is a superset and all the old functionality will still be there. Similar to the openflowplugin, the impl has changed but that should be agnostic to the end user.
- ovsdb southbound was already split from netvirt and is not related to his migration at all. There are no dependencies or impacts to ovsdb.
- code is migrated to netvirt and genius, integration features have been updated. The code is working.
- mostly verified by downstream csit, which we are working on migrating to ODL infra. old netvirt already has csit and we are updating those to include the new netvirt-vpnservice-openstack feature.
- there are new features being added to netvirt as normal with any project
- we need to work out the feature names, again similar to openflowplugin-li, but different in that we have not worked out yet if we will keep the feature name. The only code user is unimgr and that is a new requirement for boron so not really related to this migration. So changing the feature name or pom's should be an easy fix and only involve a single consumer. Documentation is still under discussion.