network parity: enable nova cloudpipe VPN

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