Context for openstack-mailing list: This is a thread from the netstack list about integrating VPN capability with Quantum. Wanted larger community feedback.
----------------- Hi Debo, Based on our discussion Tuesday, it sounds like some nova folks don't see nova cloudpipe as a path worth investing in long-term, in which case I agree that it doesn't make sense for the Quantum team to integrate with it. I'd like to get a more general nod on that from the rest of the community though, particularly the nova devs, so I am CC'ing the wider openstack list. Creating a pluggable VPN API + service either as a standalone-service or as a "sub-service" of Quantum has always been the long-term plan, so if there is no short-term nova plan, jumping to that directly makes sense. Finishing this in Essex seems ambitious to me, but given its importance to achieve "nova-network parity" for Quantum I'd love to see it happen. If we could have a "proposed" API (perhaps as a Quantum extension) and at least one open-source implementation (as well as any proprietary implementations) in time for the main essex release I think we would be in great shape. Thanks! Dan On Wed, Jan 4, 2012 at 11:17 PM, Debo Dutta (dedutta) <dedu...@cisco.com>wrote: > Hi **** > > ** ** > > After some offline discussions with Dan and Soren it was felt that we need > to have this discussion on the ML. **** > > ** ** > > Context: goal of the CP is to enable auth-ed access to a network managed > by Nova /Quantum and not publicly accessible from the Internet. **** > > ** ** > > There are 2 ways to do CP: **** > > **· **Tweaks in Nova and Quantum rework to get CP to work. > Nova-manage will spin up the CP VM but on a specific Quantum network. *We > could get this into E3. * > > **· **Soren felt that a clean solution should be independent of > Nova and be inside Quantum since the fact that we spin a CP VM is an > artifact of the way the legacy CP was implemented and that may not be the > ideal way going forward. From that perspective the above workaround planned > would be a distraction and potentially would need to be refactored. **** > > ** ** > > If we choose the 2nd route, then we will need to coverge on the quantum > API for VPN service. The design will incorporate a pluggable driver for the > following scenarios a) HW VPN devices b) VM based soft VPNs like openvpn. > **** > > ** ** > > Question to the elite netstack group: **** > > **· **Does anyone have a strong preference for the tweak that was > planned**** > > **· **For the 2nd route (i.e. API + pluggable modules), the API > could be as simple as **** > > **o **VPN.connect(args)/VPN.disconnect()**** > > **o **VPN.config(VPNConfig)**** > > **§ **Split tunneling configuring options …. **** > > **o **Network.attach_vpn_instance(VPN) and detach**** > > **o **Network.enable_vpn … instantiates a VPN instance and attaches to > the network**** > > **o **VPN object could be either SoftVPN or HardVPN**** > > ** ** > > I asked Soren if the CP tweak is critical for Quantum to be the default > manager and his opinion is a “no” and he favors a solution that is more > flexible and generic. I think if we choose the 2nd route, we should still > have a working VPN solution by E, maybe as an addon and not part of E3. ** > ** > > ** ** > > Thoughts? Opinions? Flames?**** > > ** ** > > Regards**** > > Debo**** > > ** ** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
