22:00:32 <mlavalle> #startmeeting neutron_drivers
22:00:33 <openstack> Meeting started Thu Jan 25 22:00:32 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:36 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:23 <mlavalle> Hi there!
22:01:30 <ihrachys> o/
22:01:43 <mlavalle> sup?
22:02:11 <mlavalle> armax: ping
22:02:35 <mlavalle> amotoki: ping
22:02:55 <mlavalle> ihrachys: let's wait a couple of minutes
22:05:30 <ihrachys> this late meeting doesn't seem to play nice
22:05:35 <armax> hi
22:05:42 <mlavalle> there he is
22:05:51 <armax> in between meetings
22:06:04 <mlavalle> you have time for this meeting?
22:06:09 <armax> yeah
22:06:13 <mlavalle> great
22:06:16 <armax> past meeting ran late
22:06:21 <mlavalle> we have quorum today
22:06:33 <yamamoto> hi
22:06:35 <yamamoto> sorry late
22:06:47 <mlavalle> First topic I wanted to cover was the release and FFEs
22:07:03 <mlavalle> armax: anything we should be aware of as far as the release?
22:07:41 <armax> not particularly
22:07:47 <armax> next week we’ll cut the first RC1
22:08:20 <armax> queens-3 has been cut so there’s roughly one week to get things polished up in the neutron projects
22:08:30 <armax> in time for RC1
22:08:41 <mlavalle> speaking of which....
22:08:46 <armax> https://releases.openstack.org/queens/schedule.html
22:09:04 <mlavalle> as far as I know, there is one FFE for Neutron
22:09:16 <armax> the calendar between now and the official release date
22:09:30 <mlavalle> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126582.html
22:10:07 <mlavalle> This is for new events being added for floating ips
22:10:13 <ihrachys> armax, have we released tempest plugin?
22:10:34 <armax> so the long story short is that we don’t have to
22:10:40 <armax> but we can if we want to
22:10:52 <ihrachys> it's not synced with release right?
22:10:57 <armax> and being on an indepentent release model we can do whenever
22:11:02 <ihrachys> ok
22:11:10 <armax> ihrachys: it’s must understanding that we test from master all the time
22:11:18 <ihrachys> we should release it sometimes, yes. distros will be relieved somewhat.
22:11:24 <armax> otherwise that defeats the point of branchless testing
22:11:38 <ihrachys> armax, yes, but distros may want to package it still (which they do), and tarball is handy
22:11:45 <armax> right, agreed
22:11:57 <armax> I have it on my notepad
22:12:03 <ihrachys> ok
22:12:03 <armax> I’ll get it done, sir
22:12:40 <mlavalle> going back to the FFE request
22:12:41 <ihrachys> mlavalle, to the q of new events, I think it's fine
22:12:51 <ihrachys> and yes it's better to get them early so that they can rely on it
22:13:04 <ihrachys> it's not an endorsement for patches but to include the bug
22:13:11 <mlavalle> you agree armax?
22:13:13 <ihrachys> do we track release bugs in LP?
22:13:52 <armax> mlavalle: yes
22:14:00 <mlavalle> cool
22:14:13 <mlavalle> any other FFEs you might be aware of?
22:14:35 <ihrachys> we should track https://review.openstack.org/536913 to merge
22:14:48 <armax> mlavalle: there’s one about OVN
22:15:04 <mlavalle> ihrachys: noted and agreed
22:15:09 <armax> https://review.openstack.org/#/c/534423/
22:15:50 <mlavalle> is that what Daniel mentioned in the Neutron release patch yesterday?
22:15:54 <ihrachys> yeah ovn folks were talking about some db correctness patches still in flight they wanted to include
22:15:56 <armax> mlavalle: correct
22:16:04 <armax> ihrachys: that’s the one ^
22:16:12 <ihrachys> mlavalle, not sure about the patch, but yes it was Daniel that I talked to
22:16:26 <ihrachys> armax, the only one?
22:17:17 <ihrachys> I am puzzled about which patches should we list now? what's the policy from now on? should we stop merges for any approved patches that are in flight unless they are in the list?
22:17:22 <ihrachys> (is the list in LP?)
22:17:36 <ihrachys> there are quite some patches that haven't merged, they have +W
22:17:45 <ihrachys> gate was not very welcoming so...
22:18:23 <armax> ihrachys: we used to handle this via the rc-potential bug in LP
22:18:27 <armax> s/bug/tag
22:18:31 <ihrachys> I think considering largely disastrous ways previous 2 releases went, maybe we should actually block merges except for tracked bug fixes + FFEs + gate fixes.
22:18:51 <ihrachys> armax, right. my question is, should I go and -2 / -W patches that are not in the list? :)
22:19:09 <armax> ihrachys: well, I used to that when I was in charge :)
22:19:37 <mlavalle> I think we should do it
22:19:43 <ihrachys> right. I think we should do it (tag / dashboard in LP) / forbid any merges except those in list / critical
22:19:44 <armax> I would not blame you if you did that :)
22:19:48 <ihrachys> something for mlavalle to consider
22:19:52 <armax> and btw
22:20:03 <armax> 2 releases ago I was still in charge, are you saying that I did a lousy job?
22:20:17 <armax> granted, Ocata was kinda weird cycle
22:20:19 <ihrachys> armax, haha. no, we did
22:20:35 <ihrachys> we were pushing late patches that were breaking even more things
22:20:48 <mlavalle> so let's follow this approach
22:21:01 <mlavalle> I will create the necessary list at the end of this meeting
22:21:08 <armax> ihrachys: things are never near to perfection when you need them to be!
22:21:24 <mlavalle> armax: I might need some guidnace from you but I will do it
22:21:24 <ihrachys> armax, you did great btw, all cycles
22:22:02 <yamamoto> armax: do you have a script or something to automate -2 thing?
22:22:17 <ihrachys> mlavalle, ok. then I have some more candidates that are with +W right now that we should get in.
22:22:27 <ihrachys> for example https://review.openstack.org/536367 that is a race in ovs agent
22:22:28 <armax> yamamoto: no
22:22:41 <mlavalle> ihrachys: shoot
22:22:43 <armax> I had a script that removed the -2s
22:22:56 <ihrachys> also this https://review.openstack.org/499908 though it's probably not ready right now but I want to tackle it till final
22:23:09 <ihrachys> it's a bug we introduced in pike with writable mtu
22:23:10 <armax> I was painstakingly reviewing the lot to make sure I wouldn’t had -2 unencessirly
22:23:40 <armax> though iirc henryG had a query that highlighted patches with DB migration and API extensions
22:23:56 <armax> which typically should be the ones to be blocked or looked at carefully
22:24:35 <ihrachys> actually that seems like all I have in my queue that is worthy getting early
22:24:55 <mlavalle> ihrachys: ack, we will keep track of those
22:25:27 <slaweq> ihrachys: and what about this https://review.openstack.org/#/c/537863/ ?
22:25:35 <slaweq> is it important to mention it also here?
22:25:40 <ihrachys> ah right that's a good one too
22:25:49 <mlavalle> yes
22:25:50 <ihrachys> and it's safe
22:25:57 <slaweq> thx
22:26:05 <mlavalle> actually, I just pushed it in
22:26:26 <slaweq> mlavalle: thx
22:26:43 <mlavalle> but will tag it so we track it actually meges
22:26:51 <mlavalle> merges^^^^
22:27:03 <mlavalle> that's the point of the exercise, right? :-)
22:28:07 <mlavalle> anything else regarding release, ffes?
22:29:05 <armax> none from me
22:29:19 <yamamoto> will we block patches for neutron-tempest-plugin as well?
22:29:48 <mlavalle> no, I don't think that is necessry
22:30:23 <mlavalle> in light of what we discussed at the beginning of the meeting
22:30:31 <armax> mlavalle: +1
22:30:58 <armax> that said, we should not allow patches that might test stuff that is not landing asap
22:31:15 <yamamoto> neutron-tempest-plugin changes can break the gate especially for subprojects
22:31:43 <mlavalle> so maybe we should stop merging there
22:31:46 <ihrachys> armax, I don't think you can even land it like that since we cross-gate
22:32:09 <ihrachys> usually we just do depends-on
22:32:24 <armax> ihrachys: sure,
22:32:42 <armax> but in the past I was using -2 as a deterrent to keep the gate free-ish from non critical patches
22:32:52 <ihrachys> yeah that's a consideration
22:33:00 <ihrachys> especially since gate is quite sick lately
22:33:01 <armax> might no longer be absolutely necesary nowadays
22:33:10 <ihrachys> I am trying to tackle issues one by one but it's fighing mills
22:33:14 <ihrachys> *fighting
22:33:16 <armax> I have never seen a gate not sick during relase crunch
22:33:29 <mlavalle> ok, goods points
22:33:33 <mlavalle> I'm convinced
22:33:39 <ihrachys> yeah, but we now also have zuulv3 misbehaving and meltdown slowdown
22:33:45 <mlavalle> let's freeze merging also in the tempest plugin repo
22:33:53 <ihrachys> so yeah, let's block as much as possible
22:34:06 <mlavalle> let's play it as safe as possible
22:34:08 <ihrachys> and aggressively revert non-compliant merges
22:34:32 <ihrachys> when stable/queens is created we can get back to merges.
22:34:39 <mlavalle> yeap
22:34:47 <armax> that’s the plan
22:35:22 <mlavalle> I will send a message to the ML also
22:35:49 <mlavalle> and will also reach to Daniel, to make sure there are no more patches on OVN side
22:36:09 <mlavalle> ihrachys seemed to have the impresion it was more than one
22:36:24 <mlavalle> better to be over cautious than sorry
22:36:45 <ihrachys> yeah though I could mixed things
22:36:51 <mlavalle> I know
22:36:57 <mlavalle> I am just playing it safe
22:37:13 <mlavalle> it doesn't hurt to ask
22:37:26 <ihrachys> + good
22:37:46 <mlavalle> ok
22:37:48 <mlavalle> so let'
22:38:09 <mlavalle> let's spend some time tackling RFEs
22:38:36 <mlavalle> The first one in the list is https://bugs.launchpad.net/neutron/+bug/1708460
22:38:37 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,Triaged] - Assigned to Fouad Benamrane (ftreqah)
22:38:37 <armax> before doing that
22:38:45 <mlavalle> armax: go ahead
22:38:53 <armax> mlavalle: this week is Rocky PTL self nomination
22:39:11 <mlavalle> I think it's next week
22:39:29 <armax> um
22:39:35 <armax> this might be wrong then
22:39:56 <armax> https://review.openstack.org/#/c/537918/
22:40:02 <ihrachys> it doesn't hurt to ask people caring to consider and check dates and think about it :)
22:40:11 <armax> either way
22:40:11 <mlavalle> armax: it seems you are right
22:40:29 <armax> mlavalle: of course I am
22:40:31 <armax> I am always right
22:40:36 <armax> :)
22:40:39 <mlavalle> at least per https://releases.openstack.org/queens/schedule.html
22:40:46 <mlavalle> armax: yeah, I know
22:40:51 <mlavalle> LOL
22:41:00 <armax> irrespective of the date
22:41:14 <armax> someone has to ponder on what to do :)
22:41:29 <armax> mlavalle I suppose you’re far from being burned out
22:41:30 <mlavalle> I intend to submit my candidaccy
22:41:40 <armax> kwel
22:41:42 <ihrachys> great, you can have the cake then
22:41:51 <mlavalle> it's just that for some reason I thought it was next week
22:42:01 <ihrachys> that would be a shame :)
22:42:20 <mlavalle> thanks for slapping me out of my mistake ;-)
22:42:23 <ihrachys> CNN headlines: openstack in disarray, neutron won't have a ptl, senate consultations ongoing
22:42:31 <mlavalle> LOL
22:42:53 <armax> FAKE NEWS!
22:43:12 <armax> Potus ruined it for everyone :(
22:44:08 <mlavalle> ok, let's move on
22:44:38 <mlavalle> the first RFE in the list is https://bugs.launchpad.net/neutron/+bug/1708460
22:44:39 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,Triaged] - Assigned to Fouad Benamrane (ftreqah)
22:44:54 <mlavalle> it's a good thing that slaweq is here tonight
22:45:11 <slaweq> I was reading this specs few days ago
22:45:14 <mlavalle> so he can provide input to the conversation
22:45:24 <slaweq> and to be honest I don't feel it
22:45:48 <mlavalle> I want to mention that in May of last year, we approved a similar RFE
22:46:05 <slaweq> author wants to add something like periodic monitoring of bandwidth, report it to neutron server and dynamically change QoS bandwidth limit values for ports in network
22:46:07 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1505627
22:46:09 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:46:28 <mlavalle> that hasn't made much progress
22:46:35 <slaweq> mlavalle: yes, and this similar rfe looks easier to do and more reasonable
22:46:48 <slaweq> but it require to enable ECN in vm by user
22:46:52 <ihrachys> slaweq, meaning like another daemon / thread in ovs agent that sniffs traffic?
22:46:53 <mlavalle> at the time, we pre-approved contingent on spec
22:47:07 <slaweq> ihrachys: that's what I understood from this specs
22:47:22 <ihrachys> I imagine sniffing will have enormous perf impact
22:48:01 <slaweq> so I don't know if it's good to put it in neutron - IMHO it's more like job for heat to switch bandwidth limits dynamically
22:49:14 <ihrachys> good point
22:49:29 <slaweq> so long story short, I'm not sure if https://bugs.launchpad.net/neutron/+bug/1708460 should be done all in Neutron but maybe You will read this specs and will have different opinion
22:49:30 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,Triaged] - Assigned to Fouad Benamrane (ftreqah)
22:49:59 <slaweq> and according to reedip's https://bugs.launchpad.net/neutron/+bug/1505627 IMO this is fine
22:49:59 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:50:17 <slaweq> so that's all what I can say about it :)
22:50:41 <ihrachys> I think we should suggest them to pursue the goal with an orchestrator on top like heat, and see what they have to say
22:51:02 <mlavalle> and also unify the effort
22:51:21 <mlavalle> we have two people writing very similar specs
22:51:37 <mlavalle> which drains their bandwidth and the reviewers as well
22:51:41 <mlavalle> right?
22:51:57 <ihrachys> they don't even seem similar no?
22:52:48 <ihrachys> that other RFE is for VMs to send ECN-tagged traffic
22:53:09 <ihrachys> here it's vice versa - you get signals from external network to punish VMs
22:53:14 <ihrachys> amirite?
22:53:34 <slaweq> to make ECN working it has to be enabled in whole path
22:53:52 <slaweq> and reedip's change is about to enable ECN support in neutron routers and networks
22:54:34 <slaweq> but to make this feature working in this case, VMs which send and receive traffic needs to enable ECN support also and that is not in the scope of this specs
22:54:49 <slaweq> that is https://bugs.launchpad.net/neutron/+bug/1505627
22:54:50 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:55:25 <ihrachys> yeah that makes sense. neutron path would enable for / act on tags but wouldn't dynamically throttle
22:55:41 <slaweq> and second one (https://bugs.launchpad.net/neutron/+bug/1708460) is about what to do on Neutron's side to not require enabling ECN support inside VM
22:55:42 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,Triaged] - Assigned to Fouad Benamrane (ftreqah)
22:56:09 <slaweq> but to limit bandwidth if necessary with QoS bandwidth limit rules
22:57:02 <ihrachys> ok. I think it's fine to postpone the 'reaction' RFE and ask to work on reedip's one
22:57:17 <slaweq> ihrachys: I agree with that
22:57:47 <mlavalle> and not have two efforts competing for resources
22:58:36 <mlavalle> ok, I think we have a plan for this one
22:58:44 <mlavalle> yamamoto: any thoughts?
22:58:57 * mlavalle looks at the clock
22:59:40 <yamamoto> i need to read the old one
22:59:58 <mlavalle> ok
23:00:52 <mlavalle> I assume that in principle we will postpone the 'reaction' RFE and propose continuwe working on Reedip's one
23:01:04 <mlavalle> unless yamamoto opposes after reading
23:01:10 <mlavalle> #endmeeting