openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

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) <dedutta@xxxxxxxxx>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~