22:00:51 #startmeeting neutron_drivers 22:00:51 Meeting started Thu Dec 14 22:00:51 2017 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:55 The meeting name has been set to 'neutron_drivers' 22:01:39 hi 22:01:51 hey yamamoto 22:02:25 I don't see ihrachys or amotoki connected yet 22:02:38 I know armax will join us 15 minutes late 22:03:25 so let's wait a few minutes 22:04:00 ok 22:05:22 yamamoto: this reminds me that you made a proposal about RFE process. I will chime in at the end of this meeting 22:06:38 yamamoto: did you get the reviews you requested for stable patches? 22:06:52 yes 22:07:02 :-) 22:19:28 here 22:19:55 were you folks waiting for me? 22:19:59 armax: yes 22:20:06 we didn't have quorum 22:20:11 aye 22:20:20 it's you yamamoto and me 22:20:26 so let's get rolling 22:20:33 it’s just the three of us? 22:20:49 yes 22:21:12 Firt RFE to discuss today is https://bugs.launchpad.net/neutron/+bug/1649517 22:21:12 Launchpad bug 1649517 in neutron "qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 22:23:41 no use cases given it seems 22:23:55 yeah 22:24:49 I don't see a compelling reason to implement the attribute 22:25:26 as yamamoto commented in the RFE, the user can always show the network 22:25:38 and see if the policy was inherited by the port 22:25:54 I am not strongly opinionated here 22:26:17 you see no harm? 22:27:24 no 22:27:45 there is code already, both in neutron-lib and neutron 22:29:02 it seems no one explicitly requested the feature. i guess it's appropriate to drop the rfe tag. 22:30:33 we can state in the RFE that we don't see a reason to implement this, unless a use case is provided 22:30:44 does that make sense? 22:30:54 yes 22:31:13 armax: ? 22:31:28 yup 22:31:32 ok cool 22:31:36 let's move on 22:31:59 if we need the "feature", i prefer "effective qos id" rather than "network qos id" 22:32:01 https://bugs.launchpad.net/neutron/+bug/1690425 22:32:01 Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged] 22:32:53 I had a conversation with Kris from GoDaddy regarding this 22:33:08 I posted a summary in the RFE 22:34:13 makes sense to me 22:35:11 so maybe we should start considering seriously how to implement cells in Neutron 22:35:32 armax: would that be your reading of the implication of that conversation? 22:36:06 * armax reread 22:37:07 I think the benefits of partioning neutron in a cell-like environment are a lot less evident than nova’s 22:38:18 ultimately neutron just does the wiring amongst VMs 22:38:46 yes, I think in his comements Chris agrees that we might improve sign ificantly the performance by adressing the RPC channel 22:39:10 and the mesh where the messages flow back and forth depend on where the VMs land 22:39:27 he was thinking more of fault isolation, but maybe cells is not the right construct for that 22:39:37 I am not sure tha adding an extra layer of partitioning is going to be beneficial 22:39:57 given the amount of work that would represent 22:41:26 agreed 22:41:27 if we decided to start working on the approach suggested in #5, what would be the next step? 22:42:07 I know that maybe the answer is a spec.... 22:42:28 but my question is, what would be the outline of the proposal made in the spec? 22:42:46 but we could in theory just have someone work on a prototype 22:42:48 to start with 22:42:58 because there’s so much unknown 22:43:39 a prototype using that form of RPC? 22:43:44 yes 22:43:51 ok 22:43:57 I'll think about it 22:44:11 I'll leave a comment in the RFE 22:44:17 yamamoto: any thoughts? 22:44:42 a prototype sounds fine 22:44:47 cool 22:45:28 Next one is https://bugs.launchpad.net/neutron/+bug/1705467 22:45:28 Launchpad bug 1705467 in neutron "[RFE] project ID is not verified when creating neutron resources" [Wishlist,Triaged] 22:45:54 we discussed it last week 22:46:04 Left a comment to the submitter 22:46:12 haven't heard back form him 22:46:33 so let's give him another week 22:47:00 any comments? 22:47:57 let me check 22:49:21 OK that makes sense 22:49:29 cool 22:49:34 let's move on 22:49:54 next one is https://bugs.launchpad.net/neutron/+bug/1705719 22:49:54 Launchpad bug 1705719 in neutron "[RFE] QinQ network driver" [Wishlist,Triaged] 22:50:34 The submitter was reassigned to do something else 22:50:53 and abandoned the related patches 22:51:11 since I don't see anybody else asking for this 22:51:33 um 22:51:34 too bad 22:51:48 I suggest delaying this 22:51:57 postpone 22:52:33 agree? 22:52:41 yup 22:52:56 yes 22:54:16 ok, marke postponed and left a comment 22:54:45 Next one is https://bugs.launchpad.net/neutron/+bug/1717560 22:54:45 Launchpad bug 1717560 in neutron "[RFE] allow to have no default route in DHCP host routes" [Wishlist,Triaged] 22:56:27 I think this died on the vine 22:57:10 mhhh, maybe I should ping Thomas over the next few days, to make sure that is the case 22:57:36 I can leave a comment in the RFE and try to ping him in IRC 22:57:49 I need to go back and re-read the whole thing because I am still struggling to see why we need to have this behavior driven by API changes 22:58:46 armax: would you leave a comment after re-reading? 22:59:03 after going through all the comments eralier today 22:59:08 it made sense to me 22:59:34 but we can discuss it in the RFE 22:59:42 and confirm with Thomas 22:59:59 agree? 23:00:05 OK 23:00:37 we hit the time limit 23:00:49 I just want to mention regarding https://bugs.launchpad.net/neutron/+bug/1715386 23:00:49 Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged] - Assigned to zhaobo (zhaobo6) 23:01:11 that a spec was submitted https://review.openstack.org/523658 23:01:18 as we requested a fw weeks ago 23:01:27 I did a review eralier today 23:01:35 and I intend to do another pass now 23:01:44 ack 23:01:57 I suggest yamamoto and armax wait for the next revision 23:02:06 before investing time on it 23:02:07 ok 23:02:18 still too green 23:02:22 sounds good 23:02:28 #endmeeting