14:00:08 <mlavalle> #startmeeting neutron_drivers 14:00:09 <openstack> Meeting started Fri Dec 22 14:00:08 2017 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:12 <openstack> The meeting name has been set to 'neutron_drivers' 14:00:23 <yamamoto> hi 14:00:31 <mlavalle> hi 14:00:40 <mlavalle> nice to see you yamamoto 14:00:53 <mlavalle> who else is here for the drivers meeting? 14:01:04 <ihrachys> o/ 14:01:22 <mlavalle> good morning ihrachys :-) 14:01:31 <ihrachys> indeed 14:01:44 <mlavalle> you taking off next week? 14:01:57 <ihrachys> yeah we have a shutdown till Jan 2 14:02:04 <mlavalle> Enjoy! 14:02:09 <mlavalle> how about you yamamoto? 14:02:29 <mlavalle> amotoki: ping 14:03:48 <yamamoto> i have no plan 14:03:59 <mlavalle> ok, we have quorum of 3 so let's get going 14:04:23 <mlavalle> This is the list of RFEs that we have for today: https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 14:04:52 <mlavalle> But before getting to the list, I would like to bring up an issue from the CI team 14:05:36 <mlavalle> As you may know, we have moved our Tempest plugin to its own repo 14:06:43 <mlavalle> and in the latest CI meeting it was asked whether we should consolidate all the stadium projects in the Neutron tempest plugin 14:07:00 <mlavalle> indeed bcafarel has been asking the same question in regards to sfc 14:07:12 <mlavalle> Thoughts? 14:07:30 <mlavalle> yamamoto: midonet is a stadium projects. what do you think? 14:08:12 <yamamoto> i guess it's fine for tests which can be run with other implementations 14:08:57 <mlavalle> so you have your own tempest tests that only apply to midonet? 14:09:08 <ihrachys> do you have tests that would not pass presuming the extensions needed are supported by an implementation? 14:09:58 <yamamoto> no. it depends on extensions which currently only midonet provides, but it should be skipped for others fine. 14:10:52 <mlavalle> where would you put those tests? in the midonet repo? 14:11:50 <ihrachys> mlavalle, if they just require midonet extensions those tests will be skipped, so technically it works with other implementations 14:11:51 <yamamoto> we have it in networking-midonet right now. but neutron tempest plugin is ok for us. 14:12:18 <mlavalle> ok 14:12:47 <ihrachys> I would advise not to take more work on our plates. it's a good policy to allow stadium projects to get their tests in consolidated plugin, but I would not require it. if sfc wants to have it there, we should support. 14:13:25 <mlavalle> so it would be an opt in, right? 14:13:35 <ihrachys> at the end of the day, users don't care as much about place for the tests 14:13:52 <ihrachys> yeah I would say, if sfc or midonet see benefit in it, go for it. 14:14:05 <mlavalle> I am fine with it 14:14:09 <ihrachys> if they are stretched in resources, which would not be unthinkable, let them pick their fights 14:14:23 <mlavalle> cool 14:14:37 <mlavalle> I think we have what we needed for the CI guys 14:15:49 <mlavalle> Next topic is https://bugs.launchpad.net/neutron/+bug/1649517 14:15:50 <openstack> 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) 14:16:50 <ihrachys> is the suggestion there to add another 'fake' field to port-show output that would indicate effective policy? 14:17:50 <mlavalle> yeah, have the client add that info for the user 14:18:23 <ihrachys> not override existing field right? 14:18:24 <mlavalle> instead of adding a new extension for the server 14:19:03 <mlavalle> ihrachys: that's a good point 14:19:19 <mlavalle> I don't think we have gotten to that detail in the comments so far 14:19:33 <mlavalle> what do you lean towards? 14:19:40 <ihrachys> overriding would be bad. I won't be able to understand whether it's inherited or overridden 14:20:07 <mlavalle> right 14:20:07 <ihrachys> adding a new 'fake' field effective_qos_policy_id is better 14:20:49 <mlavalle> and if the port has no policy of its own, its policy_id field would be empty, right? 14:21:15 <ihrachys> qos_policy_id = None and effective_policy_id = whatever in network 14:21:22 <mlavalle> ++ 14:21:24 <ihrachys> if it's overridden on port level, both are same 14:21:40 <mlavalle> yamamoto: thoughts? 14:21:41 <ihrachys> do we contribute it to OSC only? 14:22:26 <mlavalle> maybe neutron python client also? 14:23:19 <yamamoto> ihrachys: i agree what you said. i meant the same in comment #11 and waiting for feedback. 14:24:01 <ihrachys> mlavalle, I would at least try to make it in OSC first; if it's not accepted there, we may want to avoid introducing another discrepancy between OSC and neutronclient 14:24:27 <mlavalle> ok 14:25:41 <ihrachys> I guess now we should write it up in LP and move to appoved? 14:25:49 <ihrachys> I mean not now, but have someone assigned 14:26:09 <mlavalle> well, reedip is already working on it 14:26:35 <ihrachys> we should capture decision there so that he is aware of the path to take 14:27:19 * mlavalle writing it up 14:27:57 <yamamoto> i wonder if he has some use cases which need in neutron-api implementation for some reasons. 14:28:41 <ihrachys> good question 14:29:09 <mlavalle> I am leaving the posibility open 14:29:16 <mlavalle> in the comment 14:29:52 <ihrachys> ok, thanks mlavalle 14:32:24 <mlavalle> done 14:32:59 <mlavalle> Next onw is https://bugs.launchpad.net/neutron/+bug/1705467 14:33:00 <openstack> Launchpad bug 1705467 in neutron "[RFE] project ID is not verified when creating neutron resources" [Wishlist,Triaged] 14:34:39 <mlavalle> we discussed this two weeks ago 14:34:49 <mlavalle> haven't heard back from the submitter 14:34:56 <ihrachys> should we just move the bug to OSC? 14:35:20 <ihrachys> or you think he may still want to have neutron-api to validate id? 14:36:32 <mlavalle> I say leave a note there today that if we don't hear back from him by next meeting, we will just move it to OSC bug 14:36:43 <ihrachys> ok 14:38:09 <mlavalle> Done 14:39:13 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1715386 14:39:14 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged] - Assigned to zhaobo (zhaobo6) 14:39:49 <mlavalle> Last time we talked about this one, we asked the submitter for a draft spec 14:40:00 <mlavalle> the spec is here: https://bugs.launchpad.net/neutron/+bug/1715386 14:40:20 <mlavalle> I took a crack at reviewing the spec twice over the past 7 days or so 14:40:25 <mlavalle> and yamamoto did the same 14:41:37 <mlavalle> I say the still needs improvement but what it is being proposed is starting to look clearer 14:41:52 <mlavalle> what did you think yamamoto? 14:42:04 <yamamoto> i haven't looked the latest ps yet 14:42:15 <ihrachys> (haven't checked the spec) does it give the answer to the question from LP on why not just multiple routers? 14:44:27 <ihrachys> oh I see there is some references to qos / performance 14:47:44 <ihrachys> doesn't seem like yamamoto will answer 14:47:52 <ihrachys> or am I cut off the channel? :) 14:47:58 <mlavalle> you are not 14:48:08 <mlavalle> I assumed you were reading the spec 14:48:14 <mlavalle> but maybe you are not 14:48:21 <yamamoto> oh were you waiting for me? sorry i thought you were reading the spec :-) 14:48:53 <ihrachys> sorry. I eye balled it. I would need more time to comment on it in a more reasonable way. 14:48:56 <mlavalle> My opinion is that it is a valid RFE and that the spec needs refinement 14:49:08 <ihrachys> ok+ 14:49:55 <mlavalle> but maybe yamamoto and ihrachys would like to go through the latest ps befoire approving the RFE? 14:50:33 <yamamoto> i guess we should make the spec reading our new year homework. then decide the approval in the next meeting. 14:50:50 <mlavalle> that sounds good to me 14:51:16 <ihrachys> ok 14:51:22 <mlavalle> done 14:51:56 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1717560 14:51:57 <openstack> Launchpad bug 1717560 in neutron "[RFE] allow to have no default route in DHCP host routes" [Wishlist,Triaged] 14:52:50 <yamamoto> i want to see the answer to armax's last question 14:53:45 <mlavalle> I was hoping to catch Thomas in the channel 14:53:54 <mlavalle> is tmorin his itc nick? 14:54:15 <yamamoto> i think so 14:54:18 <ihrachys> yes 14:54:37 <mlavalle> he is not there 14:55:42 <mlavalle> so I guess we can wait for his answer. I will try to ctach him in IRC before the next meeting 14:55:58 <mlavalle> to make sure he is still listening / interested 14:56:22 * mlavalle leaving a note in the RFE 14:57:29 <mlavalle> done 14:58:16 <mlavalle> I think we ran out of time 14:58:30 <mlavalle> Thanks for attending 14:58:50 <mlavalle> happy holidays ihrachys and yamamoto 14:58:50 <ihrachys> thanks 14:58:53 <yamamoto> thank you 14:58:59 <ihrachys> enjoy the season! 14:59:14 <mlavalle> thanks for all your hard work and attendance on a Friday morning / night 14:59:25 <mlavalle> #endmeeting