14:00:18 <mlavalle> #startmeeting neutron_drivers
14:00:19 <openstack> Meeting started Fri Sep  6 14:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:28 <njohnston> o/
14:00:31 <yamamoto> hi
14:00:45 <davidsha> o/
14:00:48 <slaweq> hi
14:00:50 <ralonsoh> hi
14:01:23 <mlavalle> nice to see you back yamamoto :-)
14:02:16 <yamamoto> exhausted by holidays
14:03:00 <mlavalle> let's wait a couple of minutes
14:05:26 <mlavalle> ok, let's get going
14:05:31 <mlavalle> #topic RFEs
14:05:39 <amotoki> hi
14:05:44 <haleyb> hi
14:06:21 <mlavalle> last time we met, this RFE was discussed: https://bugs.launchpad.net/neutron/+bug/1837847
14:06:22 <openstack> Launchpad bug 1837847 in neutron "[RFE] neutron-vpnaas OpenVPN driver" [Wishlist,Triaged]
14:06:44 <mlavalle> yamamoto asked a question, submitter responded and asked questions
14:06:53 <mlavalle> I made a suggestion last night
14:07:12 <mlavalle> so let's see how much progress we can make with it this morning
14:08:18 <njohnston> I also thought about an L2 agent extension for this
14:09:21 <slaweq> njohnston: L2 or L3 agent extension?
14:09:26 <slaweq> I think it's more for L3 agent, no?
14:10:20 <njohnston> I think the part that I'd like more information on is the method by which OpenVPN communicates to the agent; submitter described it as "OpenVPN calls my learn-address hook" and I just want to get more details on that path
14:11:02 <njohnston> slaweq: It might well be operating at both L2 and L3 levels, but fundamentally port provisioning/deprovisioning would be an L2 function, yes?
14:11:32 <njohnston> (looking at comment #6)
14:14:00 <slaweq> njohnston: provisioning yes, but creating necessary resources for vpnaas - I'm not sure - but that is just implementation detail IMO :)
14:14:32 <mlavalle> submitter offered to join the meeting after his vacation, so I was hoping he would join today
14:14:56 <amotoki> I wonder how L2 VPN connection is modeled in the API. The submitter seems to think no change in API but I'm not sure. it looks like yamamoto has a same question but it is still unclear.
14:15:14 <slaweq> I wonder how such ports will be cleaned as last part of comment #6 says IMO that there might be some problem with it
14:17:38 <yamamoto> i'm still not sure about the api. 1. the use of router for l2 vpn looks a bit awkward 2. to which network it's connected when the router has more than one router ports?
14:18:51 <amotoki> one idea is to request the submitter to write a spec to explain more detail on this. Some drawings and detail explanation might help us understand and clarify the proposal.
14:19:49 <mlavalle> that's a pretty good suggestion amotoki
14:20:09 <amotoki> we have many questions and launchpad comments limits our clear understanding...
14:20:26 <slaweq> amotoki: +1
14:20:55 <mlavalle> here's what I propose to make sure submitter can address all our questions:
14:21:29 <mlavalle> 1) each one of you who have questions, please add a comment with you question(s) to the RFE
14:22:12 <mlavalle> 2) After your questions, I'll add another comment suggesting a spec with diagrams stating that your questions should be answered in that spec
14:22:16 <mlavalle> does that work?
14:22:28 <amotoki> +1
14:22:32 <njohnston> +1
14:22:34 <slaweq> +1
14:22:45 <haleyb> +1
14:23:02 <yamamoto> +1
14:23:25 <mlavalle> ok, that's the plan forward.... I'll give you 5 minutes to leave your comments
14:25:25 <slaweq> I'm done :)
14:29:01 <mlavalle> ok cool
14:29:26 <mlavalle> next one is https://bugs.launchpad.net/neutron/+bug/1840136
14:29:27 <openstack> Launchpad bug 1840136 in neutron "[RFE] Add new config option to enable IGMP snooping in ovs" [Wishlist,New] - Assigned to Slawek Kaplonski (slaweq)
14:31:44 <slaweq> that is something easy and small in implementation
14:32:07 <slaweq> and it would be used by both ovs agent and networking-ovn
14:32:59 <mlavalle> would you implement it?
14:33:08 <slaweq> in ml2/ovs yes
14:33:15 <mlavalle> cool
14:33:16 <amotoki> a new config option is proposed. Is there any difference from tenant user POV between when igmp enabled and disabled cases?
14:33:19 <slaweq> in networking-ovn - I don't know exactly
14:35:20 <slaweq> amotoki: in case of ml2/ovs processing of igmp packets is on vswitchd always AFAICT, so if there would be any limitations with processing those packets it will be on ovs-vswitchd
14:35:35 <slaweq> in case of networking-ovn it is a bit different underneath
14:35:52 <slaweq> as ovn has got also something called querier which should be also enabled
14:36:07 <slaweq> and igmp packets are then always processes by ovn-controller
14:37:02 <slaweq> so in case of flood not all igmp packets may reach ports
14:37:17 <slaweq> and that's why we don't want to enable it always but add config option for that
14:39:16 <amotoki> I just wonder there is visible difference from tenant user point of view. tenant users are not aware of the config option, so we need to provide same behavior for users regardless of the option value.
14:42:12 <slaweq> amotoki: tbh the only visible difference for users may be that if this will be enabled, vms not subscribed to some multicast group will not get this multicast traffic
14:43:49 <amotoki> slaweq: if so, that's fine as this is the normal behavior of multicast traffic.
14:44:35 <mlavalle> I'm ok moving ahead with this RFE
14:45:19 <ralonsoh> +1
14:45:28 <amotoki> i'm okay too
14:46:13 <yamamoto> me too
14:46:37 <haleyb> +1, would be good to tag an ovn resource too
14:46:57 <njohnston> +1
14:47:20 <slaweq> haleyb: You mean add ovn tag to the launchpad?
14:48:03 <mlavalle> ok, approved it is
14:48:05 <haleyb> slaweq: well, just to get it implemented in both ml2/ovs and ovn
14:48:21 <slaweq> haleyb: yes, dalvarez is also aware of it :)
14:48:26 <haleyb> ack
14:48:28 <slaweq> but I will add such tag to it
14:48:36 <slaweq> thx all for approving this
14:49:07 <mlavalle> Those are all the RFEs for today
14:49:28 <mlavalle> Thanks for attending
14:49:38 <mlavalle> have a great weekend!
14:49:44 <slaweq> thx
14:49:47 <ralonsoh> bye
14:49:47 <amotoki> thanks
14:49:49 <slaweq> have a great weekend :)
14:49:50 <haleyb> bye
14:49:50 <mlavalle> #endmeeting