In general I completely agree on the VPN service with set of APIs. That's the main motivation, we proposed a "Network Extensions Proposal aka Hybrid Cloud Service for Network resources" in the last Boston Essex summit. The proposal initially is to "solve" the VPN based on IPsec as a first iteration with set of "prototype APIs". Though the long term goal is to evolve and have a well abstracted APIs for any of the underlying "transport schemes e.g. MPLS VPN or other overlay/tunneling schemes".
Please refer to http://wiki.openstack.org/NetstackEssexSummit?action=AttachFile&do=get&target=HCS_Essex_2011 (please save this file as .pdf for some reason the file extension is missing) As discussed and concluded in the Boston summit, we are planning to develop a "prototype" based on the above proposal for the upcoming "F Summit" for further pointed discussions on the APIs and models. Also agree with this thread that its very very aggressive to target Essex timelines for having a separate set of "VPN" APIs at production ready. So it would be great if we can find out achieving a nova-network parity for E3/E4 milestones and take up the separate or sub Quantum VPN service post Essex. Ram From: netstack-bounces+radurair=cisco....@lists.launchpad.net [mailto:netstack-bounces+radurair=cisco....@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Wednesday, January 11, 2012 10:15 AM To: Salvatore Orlando Cc: netstack@lists.launchpad.net; Soren Hansen Subject: Re: [Netstack] cloudpipe stuff Hi folks, This was one issue that we weren't able to close out during the netstack team meeting yesterday. Debo was traveling and unable to attend the meeting, so we're looking for input from him. See below for the full log, but the general feeling expressed on IRC was that there are a lot of tricky questions to handle when introducing Quantum's first "sub-service" in general and when designing a "VPN API" in particular, and that it seemed like a lot of discussion + code churn to try to complete right at the end of a cycle . What we felt was missing was more info on why we cannot (or should not) make changes to nova to plug a cloudpipe VM into a Quantum network. I think Debo + some Nova team members have discussed details here, but would be good to get them out on the list more generally, so everyone can weigh in. My general goals are: - have a high-confidence dev plan for a viable quantum + vpn story in time for Essex - avoid anyone doing significant throw-away work - avoid adding too much additional ML discussion + code churn load on the (quite small) team of core quantum devs, given that we already have a lot of other work we need to do to achieve our goals of "production quality" and "nova-network parity" for Essex. If others have additional or conflicting goals, would be good to voice those here. Thanks, Dan 22:11:56 <danwent> Ok, next issue may not be ready to close, but debo wanted me to bring it up, as the clock is ticking 22:11:59 <danwent> VPN thread 22:12:25 <danwent> question is whether to modify Nova to make cloudpipe work with quantum, or do separate service. 22:12:37 <cdub> how realistic is new api? 22:12:42 <danwent> won't rehash the discussion, but please respond on this quickly, as if we decide to do it in nova, we need to act VERY quickly. 22:13:02 <danwent> cdub: to be honest I think having this by essex is risky 22:13:16 <cdub> danwent: by separate service you mean quantum l3, not new foobar service, right? 22:13:25 <cdub> i do too, but you'd have better idea ;) 22:13:42 <danwent> cdub: perhaps "sub-service" of quantum is a better term. 22:13:50 <cdub> *nod* 22:13:53 <danwent> I think vpn would be separate from L3 though 22:14:04 <cdub> as in, quantum vpn api 22:14:24 <danwent> but as this highlights, tackling our first sub-service is a non-trivial task with a lot of questions to tackle... not something that will happen quickly. 22:14:29 <danwent> cdub: yup 22:14:46 <cdub> certainly makes sense to me long term, i suspect it will put essex at risk of not having vpn though 22:14:51 <salv-orlando> Still, whether VPN APIs are fit to be in Quantum or not, is something that needs to be discussed. Hence, recalling how fierce our discussions typycally are, getting it for Essex sounds really risky! 22:15:46 <danwent> Ok, so as the output of this discussion, I'll take there there is no consensus on this, at least for #2. I'd like to hear a bit more from the nova folks as to why simply tweaks can't make cloudpipe work with Quantum manager. 22:16:02 <danwent> I think debo knows more about this, which will help us make an informed decision. 22:16:22 <danwent> #todo #debo email netstack about cost of doing nova cloupipe + quantum work. On Tue, Jan 10, 2012 at 10:44 AM, Dan Wendlandt <d...@nicira.com> wrote: On Mon, Jan 9, 2012 at 6:29 AM, Salvatore Orlando <salvatore.orla...@eu.citrix.com> wrote: 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 is correct that at the summit was agreed to focus on Nova parity, not designing entirely new services, as the initial step. The goal was to focus our limited dev resources on making Quantum production quality and operationally useful for people implementing core Nova use cases. Once that was achieved, we would then spend project resources designing new services and API. I think that is still the right goal and we're definitely still in the first "get to production quality" stage, but I don't want to pursue this to a degree that means we're doing throw-away work that openstack users won't really benefit from. Based on a bit of time looking at the cloudpipe code, I had originally estimated that the work to get cloudpipe working with Quantum would be pretty minimal, and thus was worth doing as part of nova parity. But comments from Soren + Trey that investing in cloudpipe is not time well spent carry a lot of weight in my book, and I don't want to have any dev working on something that not a good use of time. And if we don't do the VPN nova-parity work, then it makes sense for VPN to be one of the first "quantum services" we focus on, though again, we need to make sure it doesn't distract us from achieving our core goal of production quality. In that sense, I think it probably makes sense to expose any VPN API as an extension, so we can "prove" that it is the right abstraction while still letting early adopters leverage the functionality. This is inline with the general approach that every API should be an extension before it is "core". Thoughts? Dan Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando <mailto:netstack-bounces%2Bsalvatore.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> 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 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 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
