14:00:30 <mlavalle> #startmeeting neutron_drivers 14:00:30 <openstack> Meeting started Fri Jan 5 14:00:30 2018 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:33 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:14 <yamamoto> hi 14:01:28 <mlavalle> Hi yamamoto, happy New Year! 14:01:37 <yamamoto> happy new year 14:01:47 <amotoki> hi happy new year 14:02:07 <mlavalle> hi amotoki! 14:02:18 <mlavalle> is this your first day after vacation? 14:02:38 <amotoki> yes, so I haven't reviewed much.. 14:02:45 <yamamoto> 2nd day for me 14:02:46 <mlavalle> that's ok 14:02:50 <mlavalle> ohhhh 14:03:04 <mlavalle> did you guys went anywhere nice? 14:03:19 <amotoki> in japan we usually have new year holidays till Jan 3 14:03:32 <mlavalle> ah, good to know 14:03:57 <amotoki> instead of Christmas :) 14:04:09 <mlavalle> of course 14:04:22 <mlavalle> ok, let's get going 14:05:40 <mlavalle> yamamoto: thanks for the patchset with the new rfe labels 14:06:03 <amotoki> https://review.openstack.org/#/c/528189/ 14:06:34 <mlavalle> amotoki: thanks 14:06:46 <mlavalle> I think we are all in agreement. Aren't we? 14:06:55 <amotoki> yes, sure 14:07:29 <mlavalle> so if by the end of my day today we don't get any other feedback, I am going to W+ it 14:07:39 <mlavalle> ok? 14:07:45 <yamamoto> fine for me 14:07:52 <amotoki> sounds good 14:07:56 <mlavalle> ok 14:08:10 <yamamoto> i'll add new tags to existing rfes once it was merged 14:08:21 <mlavalle> This is the list we have today: https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 14:09:07 <mlavalle> I am going to skip Neutron cells aware. The agreement last time was to have someone start developing a POC 14:09:37 <mlavalle> using approach in #5 14:10:01 <mlavalle> unless anyone wants to add something.... 14:10:34 <yamamoto> nothing to add from me 14:11:04 <amotoki> is anyone moving this forward? 14:11:08 <amotoki> on POC 14:11:19 <mlavalle> not that I am aware of 14:11:26 <mlavalle> amotoki: interested? 14:11:49 <amotoki> i haven't looked into it yet 14:12:06 <mlavalle> ok, take a look and let us know 14:12:18 <amotoki> i am interested in it, but I need to move some API stuffs forward 14:12:52 <mlavalle> ok, let us know if you make free up some bandwidth for it 14:13:02 <mlavalle> can free up^^^^ 14:13:17 <amotoki> okay 14:13:34 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1715386 14:13:35 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged] - Assigned to zhaobo (zhaobo6) 14:16:29 <mlavalle> I made another pass a copuple of days ago at the spec here: https://review.openstack.org/#/c/523658 14:17:49 <amotoki> i haven't looked at the spec proposed yet. From the bug description, it sounds a valid use case and the spec will help our understanding. 14:18:26 <mlavalle> can you elaborate on the valid use case part? 14:18:55 <mlavalle> I would like to hear your thoughts 14:20:38 <amotoki> ah... the bug description says "some specified source IP/CIDR". it sounds source routing. 14:20:47 <mlavalle> correct 14:20:54 <mlavalle> source based routing 14:21:02 <amotoki> my original impression might be wrong.... 14:21:17 <mlavalle> no, it is correct 14:21:33 <mlavalle> at its essence, the proposal is source based routing 14:22:00 <amotoki> what I thoguht first is something like AWS VPC, where we can determine external gateway based on routing table. 14:22:21 <amotoki> it is not based on source-based routing 14:23:05 <mlavalle> ahhh, ok I see what you say 14:24:33 <amotoki> yamamoto: i think you already looked into the spec. any comment? 14:25:00 <haleyb> ihar had a good point - can we use SFC for this, and if so, why do it here again? 14:25:31 <yamamoto> i have never understood why multiple routers are not enough for the given use cases. 14:26:47 <amotoki> yeah, ihar had a good point. In my understanding, the current SFC does not support this model, but it sounds worth investigated 14:27:18 <mlavalle> amotoki, haleyb: if you have some time, would you leave some feedback in the spec? 14:27:37 <amotoki> sure 14:28:04 <mlavalle> any other comments from someone? 14:28:13 <haleyb> mlavalle: sure. my other thought is a routing VM 14:29:45 <mlavalle> ok, moving on... 14:29:51 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1717560 14:29:52 <openstack> Launchpad bug 1717560 in neutron "[RFE] allow to have no default route in DHCP host routes" [Wishlist,Triaged] 14:32:44 <mlavalle> For this one armax made an alternative proposal in comment #15, based DHCP extra options 14:33:16 <mlavalle> haven't heard back from Thomas 14:33:44 <mlavalle> tried to ping him in the Neutron channel 14:33:48 <mlavalle> he is not there 14:35:09 <haleyb> one other thing i didn't see in the bug is what about the case where a VM has two interfaces in the same subnet? egress spoof checking causes problems with that, and could even in other cases 14:35:31 <haleyb> it's a little orhagonal i understand 14:35:50 <mlavalle> My thinking is that if we don't here from him by next meeting, we can conclude he doesn't want to pursue it anymore 14:35:56 <mlavalle> hear^^^^ 14:36:39 <haleyb> but if i have two interfaces in different subnets i have to configure the VM to always use the source IP only on the interface it is configured on, which is part of the special setup he mentions 14:36:45 <mlavalle> I was tempted to arrive at that conclusion last night. But with the Holidays, I thought we shoould probably wait a little longer 14:36:47 <haleyb> neutron can't help with taht 14:37:22 <mlavalle> haleyb: would you leave some feedback there 14:37:25 <mlavalle> ? 14:37:42 <haleyb> mlavalle: sure, i hadn't even noticed that bug before 14:39:04 <mlavalle> any other thoughts from someone? 14:39:18 <yamamoto> +1 to wait for another week. but i guess it isn't critical as far as he can re-open it. 14:40:51 * mlavalle leaving a note in the RFE 14:42:27 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1718605 14:42:28 <openstack> Launchpad bug 1718605 in neutron "[RFE] Support sub-string matching when filtering port with IP address" [Wishlist,Triaged] - Assigned to hongbin (hongbin034) 14:45:25 <haleyb> mlavalle: who is the approver for this one? there were two reviews and they seem about complete 14:45:28 <mlavalle> I had a conversation with mriedem last night about it. Left a summary in#8 14:45:29 <amotoki> what we need is now clear and I think we approve this. 14:45:59 * haleyb didn't want to +2 since someone else might approve 14:46:44 <mlavalle> haleyb: yeah, I also wanted to wait for this meeting to formally approve the work 14:46:58 <mlavalle> yamamoto: do you agree approving this? 14:47:02 <yamamoto> yes 14:47:09 <mlavalle> haleyb: you good with it? 14:48:14 <mlavalle> ok, approved it is 14:48:21 <haleyb> mlavalle: yes i think they're fine, would be good to have someone else look at the changes since i only remember slaweq recently 14:48:35 <mlavalle> haleyb: I will review today 14:49:13 <mlavalle> ok, approved it is 14:50:02 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1727578 14:50:03 <openstack> Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Triaged] 14:52:23 <mlavalle> This one was brought during the QoS meeting by slaweq this past Tuesday 14:53:08 <mlavalle> he indicated interest on it from the QoS team point of view, so I asked him to mark it triaged, so it can be discussed here 14:53:18 <yamamoto> i guess the feature is nice to have. to me it isn't clear how the reference impl would look like though. 14:53:24 <slaweq> hi, there is some specs for it also: https://review.openstack.org/#/c/531074/ 14:53:35 <slaweq> but I didn't have time to read it yet 14:54:28 <mlavalle> would we feel comfortable approving the RFE and taking the discussion to the spec? 14:54:38 <yamamoto> yes 14:55:01 <mlavalle> amotoki: how about you? 14:55:11 <amotoki> I am fine to approve the RFE though i am not sure how we can actually implement it in the reference impl, but it can be dsicussed in the spec 14:55:22 <mlavalle> ok cool 14:56:19 <mlavalle> approved it is 14:56:34 <mlavalle> and that was the last RFE we had for today 14:56:58 <mlavalle> so we will be returning a whopping 4 minutes to everybody's agenda :-) 14:57:27 <mlavalle> haleyb, slaweq: thanks for popping in. Your insight is always welcome 14:57:46 <slaweq> :) 14:57:48 <mlavalle> next meeting is on Thursday, 2200UTC 14:57:51 <haleyb> np, glad to help 14:58:04 <mlavalle> #endmeeting