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