network parity: enable nova cloudpipe VPN

Registered by Brad Hall on 2011-10-17

This blueprint has been superseded. See the newer blueprint "Add Nova VPN parity to Quantum" for updated plans.

We need the ability to use VPNs with the QuantumManager

Blueprint information

Status:
Complete
Approver:
dan wendlandt
Priority:
Low
Drafter:
None
Direction:
Needs approval
Assignee:
Debo~ Dutta
Definition:
Superseded
Series goal:
None
Implementation:
Deferred
Milestone target:
None
Completed by
Mark McClain on 2012-10-29

Related branches

Sprints

Whiteboard

Update: Vish said he is working on some changes to nova that will hopefully let VPNs work without any special handling. Instead, it would just be spinning up a VM with a special image. Presumably this would use floating IPs, which are being added to QuantumManager in Essex-3.

As a result, we're putting this work on hold, not targeting essex-3. Targeting it for essex-4 just to track that we have some solution for VPN + Quantum in Essex.

-----------------

Its great to see this BP. I have a few comments.

Wishlist:
* This should work with quantum as well other plugins
* This should work with soft VPN terminators as well as HW ones (pick any popular one for a usecase!)

I havent done a deep dive into the details but do you think it might be better to shrink wrap this feature as a L3 service but integrated within quantum. Sample API:
nova.api.l3service.cloudpipe --->
get_encoded_zip
initiate_service (would either do launch_vpn_instance or config_vpn_concentrator depending on type of service)
setup_key_pair
setup_security_group (would push a security group in case of launch_vpn_instance)
set/get_vpn_public_ip
set/get_vpn_public_port

Today: for VPN access, .2 is reserved and some IPs at the end of the pool are reserved for the instances.
Tomorrow: One can configure the vpn_public_ip and vpn_public_port in the DB using the L3 service for each network. When clients connect to this ip/port, we need to map it to port 1194 of our cloudpipe instance. L3 service should do the mapping/routing.

References:
https://github.com/openstack/nova/tree/master/nova/cloudpipe

thx
debo

---------

hey debo.

thanks for your thoughts. I think Brad's blueprint is focused just on the "short-term" step of just making sure that the existing nova cloud-pipe mechanism works with Quantum networks. Creating a more generic "service" around VPN connectivity that supports different terminator types, etc. is a more long-term step that deserves it own blueprints (or even, its own set of blueprints!).

I think the main changes we need just to reach nova-parity for cloudpipe are:
* The existing VPN code assumes that a project only has a single network, and the VPN is automatically attached to that network. With Quantum, a project can have many networks. Thus, we must change the nova-manage command that creates a VPN and let it take a network UUID. The cloudpipe VM will be spun up and attached to that network.
* the internal database schema for storing VPN data will likely need to change, as we no longer have an entry in the "networks" table for each Quantum network.
* nova-manage commands that describe VPN data will probably need to be tweaked, given that each VPN is now also associated with a specific network.
* There should probably be some integration with Melange to understand what subnet the network uses, and thus what internal config the VPN box should hand out.

- Dan

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.