14:00:22 #startmeeting neutron_drivers 14:00:23 Meeting started Fri Sep 20 14:00:22 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:28 The meeting name has been set to 'neutron_drivers' 14:00:32 hi 14:00:32 hi 14:00:34 hi 14:00:39 hi 14:00:42 hi 14:01:29 let's wait 1 minute 14:01:41 o/ 14:02:06 hi 14:02:42 ok, we have the usual suspects now... let's get going 14:02:50 #topic RFEs 14:03:34 last meeting we discussed https://bugs.launchpad.net/neutron/+bug/1837847 14:03:35 Launchpad bug 1837847 in neutron "[RFE] neutron-vpnaas OpenVPN driver" [Wishlist,Triaged] 14:03:53 and we asked adriaan42 to propose a spec to clarify 14:04:36 which he did https://review.opendev.org/#/c/680990/ 14:06:52 thanks adriaan42! 14:07:13 after reading the spc last night, I leaned towards option 3 14:07:23 seems simpler to me 14:07:58 there are people in this meeting with better knowledge of vpnaas, though 14:09:33 Yes, I think so too. yamamoto asked a good question, whether the two dhcp services (neutron's and openvpn's) would conflict. I'll have to check on that. 14:10:49 this way the vpn server becomes just a conduit for the l2 traffic 14:12:15 from the other hand, solution 1 seems "more correct" from Neutron's point of view IMO, as then neutron manage all ports, e.g. dhcp 14:12:18 correct? 14:13:19 yes, I was thinking that from that perspective vpnaas would be acting in a similar way to how kuryr acts 14:13:30 it sounds reasonable that IP address is owned by a neutron port 14:17:30 adriaan42: based on what you know now do you see still viable continuing with a Neutron port approach? 14:20:50 njohnston pointed out that usually, port creation is initiated by the neutron server, and not by agents. I'm not clear what would be involved if we do this anyway. It may require a new RPC call so the agent can initiate port creation? 14:23:05 adriaan42: isn't it like that e.g. in case of dhcp agents that agent is creating port in network? 14:23:12 I'm not sure, just asking :) 14:23:19 adriaan42: An analogue can be found in how the Kuryr project creates ports. It issues API requests to neutron server to create the ports and bind them to the compute nodes where it needs them 14:25:30 adriaan42: I think that sticking with neutron API calls is better because it also is better able to accomodate the OVN model where there is no agent RPC communication 14:25:57 perhaps it depends on how we add openvpn support. If the vpnaas plugin/driver knows a client IP address, the plugin can assign IP address by creating a port internally in neutron. 14:26:11 if it is done by an agent, we need an extra RPC call. 14:27:29 maybe stupid idea but maybe client can do call to neutron API and create such port? 14:27:47 I'm also not sure. But that's two good pointers. I'll look into the dhcp agent and Kuryr, and try to implement something similar. 14:28:30 slaweq that is my "Alternative 2", just leave it up to the client. 14:28:58 adriaan42: ahh, right :) 14:30:02 adriaan42: how many clients does your use case likely have? 14:31:53 yamamoto: I expect few clients, or even just one. A user will create a number of instances in a Neutron network and then use the VPN to interact with them. 14:36:52 adriaan42: So let's say using scenario 1, is this how it would go? vpnaas gets a neutron port, complete with ip address. vpnaas turns that over to openvpn which then uses it as the endpoint for the vpn tunnel. 14:38:01 routing traffic to the ip address neutron gave as a gateway to the network behind the tunnel would be outside neutron's scope 14:38:12 is that a fairly accurate view, adriaan42? 14:40:09 hmm, I was thinking of the server side of the tunnel, not the client side of the tunnel. I think that is where my confusion is 14:40:14 njohnston I'm not sure. Looking from the neutron network, the VPN clients are not behind a (L3) gateway. They would be in the same L2 domain. 14:40:39 Oh, yes the server side is a different question 14:44:34 adriaan42: I am taking a step back here. why the need of placing the remote clients in the same L2 domain? can you elaborate a little bit on the use case 14:44:38 ? 14:46:08 adriaan42: also, will 100% of traffic be run through the VPN? Or will it be just traffic destined for certain CIDR blocks? 14:46:19 from the client side of the VPN I mean 14:47:52 if only traffic routed to certain CIDR blocks needs to be routed through the VPN then I think this could be accomplished very easily using the extraroutes API 14:48:09 in the interest of moving forward here's what I have in mind: 14:48:15 mlavalle part of the traffic is multicast. In fact, the first thing that happens when talking to my instances is a multicast-based discovery protocol. 14:48:44 adriaan42: thanks for the clarification 14:49:01 in the interest of moving forward, here's what I propose: 14:49:47 1) It seems to me that adriaan42 has valid / good need for a L2 VPN.... so if we all agree on that, let's approve the RFE 14:50:22 2) Let's continue the detailed discussion of the how in the spec 14:50:50 +1 14:50:59 totally agree 14:51:00 +1 14:51:03 +1 14:51:31 given that the team seems to lean towards a solution where the ips are owned by a neutron port, we can continue with the idea on converging on that 14:51:50 adriaan42: is this helpful 14:52:03 Yes, definitely. 14:52:30 I'll do some homework, and then update the spec. 14:53:02 adriaan42: one thing you didn't answer above was if based on what you know today, does a neutron port based approach contnue being viable? 14:53:21 possible? 14:53:50 I think it's possible. 14:54:03 I will read into how the dhcp agent and kuryr do it. 14:54:29 ok, so since this team seems to be leaning towards a neutron port owning the ip, let's continue the development of the spec under that assumption 14:54:38 does this make sense to everybody? 14:55:02 yes 14:55:10 yes 14:55:13 yes 14:55:19 yes 14:55:51 adriaan42: Ping me if you want more info on how kuryr is wiring things up 14:56:17 ok cool, since we have a path forward with a working hypothesis, let's follow it now 14:56:22 thanks, yes I will 14:57:06 adriaan42: in a few minutes I'll mark the RFE as approved and let's focus on the spec 14:57:45 and with that, since we are close to the top of the hour, I wish everybody a nice weekend 14:57:57 thx, You too :) 14:58:01 thanks, you too mlavalle! 14:58:03 and thank you all for your time 14:58:08 thanks 14:58:12 Thank you! 14:58:12 #endmeeting