14:00:22 <mlavalle> #startmeeting neutron_drivers
14:00:23 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:28 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:32 <yamamoto> hi
14:00:32 <ralonsoh> hi
14:00:34 <slaweq> hi
14:00:39 <haleyb> hi
14:00:42 <adriaan42> hi
14:01:29 <mlavalle> let's wait 1 minute
14:01:41 <njohnston> o/
14:02:06 <amotoki> hi
14:02:42 <mlavalle> ok, we have the usual suspects now... let's get going
14:02:50 <mlavalle> #topic RFEs
14:03:34 <mlavalle> last meeting we discussed https://bugs.launchpad.net/neutron/+bug/1837847
14:03:35 <openstack> Launchpad bug 1837847 in neutron "[RFE] neutron-vpnaas OpenVPN driver" [Wishlist,Triaged]
14:03:53 <mlavalle> and we asked adriaan42 to propose a spec to clarify
14:04:36 <mlavalle> which he did https://review.opendev.org/#/c/680990/
14:06:52 <mlavalle> thanks adriaan42!
14:07:13 <mlavalle> after reading the spc last night, I leaned towards option 3
14:07:23 <mlavalle> seems simpler to me
14:07:58 <mlavalle> there are people in this meeting with better knowledge of vpnaas, though
14:09:33 <adriaan42> 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 <mlavalle> this way the vpn server becomes just a conduit for the l2 traffic
14:12:15 <slaweq> 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 <slaweq> correct?
14:13:19 <njohnston> yes, I was thinking that from that perspective vpnaas would be acting in a similar way to how kuryr acts
14:13:30 <amotoki> it sounds reasonable that  IP address is owned by a neutron port
14:17:30 <mlavalle> adriaan42: based on what you know now do you see still viable continuing with a Neutron port approach?
14:20:50 <adriaan42> 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 <slaweq> adriaan42: isn't it like that e.g. in case of dhcp agents that agent is creating port in network?
14:23:12 <slaweq> I'm not sure, just asking :)
14:23:19 <njohnston> 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 <njohnston> 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 <amotoki> 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 <amotoki> if it is done by an agent, we need an extra RPC call.
14:27:29 <slaweq> maybe stupid idea but maybe client can do call to neutron API and create such port?
14:27:47 <adriaan42> 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 <adriaan42> slaweq that is my "Alternative 2", just leave it up to the client.
14:28:58 <slaweq> adriaan42: ahh, right :)
14:30:02 <yamamoto> adriaan42: how many clients does your use case likely have?
14:31:53 <adriaan42> 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 <njohnston> 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 <njohnston> 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 <njohnston> is that a fairly accurate view, adriaan42?
14:40:09 <njohnston> 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 <adriaan42> 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 <adriaan42> Oh, yes the server side is a different question
14:44:34 <mlavalle> 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 <mlavalle> ?
14:46:08 <njohnston> 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 <njohnston> from the client side of the VPN I mean
14:47:52 <njohnston> 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 <mlavalle> in the interest of moving forward here's what I have in mind:
14:48:15 <adriaan42> 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 <mlavalle> adriaan42: thanks for the clarification
14:49:01 <mlavalle> in the interest of moving forward, here's what I propose:
14:49:47 <mlavalle> 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 <mlavalle> 2) Let's continue the detailed discussion of the how in the spec
14:50:50 <njohnston> +1
14:50:59 <amotoki> totally agree
14:51:00 <slaweq> +1
14:51:03 <yamamoto> +1
14:51:31 <mlavalle> 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 <mlavalle> adriaan42: is this helpful
14:52:03 <adriaan42> Yes, definitely.
14:52:30 <adriaan42> I'll do some homework, and then update the spec.
14:53:02 <mlavalle> 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 <mlavalle> possible?
14:53:50 <adriaan42> I think it's possible.
14:54:03 <adriaan42> I will read into how the dhcp agent and kuryr do it.
14:54:29 <mlavalle> 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 <mlavalle> does this make sense to everybody?
14:55:02 <slaweq> yes
14:55:10 <amotoki> yes
14:55:13 <adriaan42> yes
14:55:19 <njohnston> yes
14:55:51 <njohnston> adriaan42: Ping me if you want more info on how kuryr is wiring things up
14:56:17 <mlavalle> ok cool, since we have a path forward with a working hypothesis, let's follow it now
14:56:22 <adriaan42> thanks, yes I will
14:57:06 <mlavalle> adriaan42: in a few minutes I'll mark the RFE as approved and let's focus on the spec
14:57:45 <mlavalle> and with that, since we are close to the top of the hour, I wish everybody a nice weekend
14:57:57 <slaweq> thx, You too :)
14:58:01 <njohnston> thanks, you too mlavalle!
14:58:03 <mlavalle> and thank you all for your time
14:58:08 <amotoki> thanks
14:58:12 <adriaan42> Thank you!
14:58:12 <mlavalle> #endmeeting