Ideally I would choose the 2nd route as well. However, this kind of reminds me of the discussions we were having at the design summit over whether we should rely on a new service/extension of the Quantum API for achieving feature parity (e.g. The ‘L3 service’) or try to re-use as much as possible from what’s currently available in Nova, and perform all the integration in the Quantum Manager, at least for the Essex release.
I remember than the agreement was to achieve feature parity by working on the Quantum Manager; if this is correct we should probably follow the first route for this Essex release. Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of Robert Starmer (starmer) Sent: 07 January 2012 06:10 To: Debo Dutta (dedutta) Cc: netstack@lists.launchpad.net; Soren Hansen Subject: Re: [Netstack] cloudpipe stuff The second route is the right one. IMHO we shouldn't be putting "hacks" into the system when there is a clean scalable and properly modular model by which we can proceed. Getting this done by E, even if it's not production ready, is a great goal, and would allow those that can make near term use of it to get a head start on the next iteration. If it can be made production ready by then, even better! So +1 for route 2 Robert Sent from my tablet On Jan 4, 2012, at 21:19, "Debo Dutta (dedutta)" <dedu...@cisco.com<mailto: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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
