14:00:29 #startmeeting networking 14:00:30 Meeting started Tue Apr 9 14:00:29 2019 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:33 The meeting name has been set to 'networking' 14:00:35 o/ 14:00:37 o/ 14:00:40 \o 14:00:41 o/ 14:00:50 \o/ 14:01:35 Welcome everybody! 14:01:54 hi 14:02:06 Let's get going 14:02:20 #topic Announcements 14:03:21 Per https://releases.openstack.org/stein/schedule.html, this is the week the community releases Stein 14:03:36 hi 14:03:55 we had a last minute small hicup last week with some of the bulk port creation code 14:04:10 but we merged the fix on time, so everything is good 14:04:25 mlavalle: so do we need to push a tag for stable/stein ? 14:04:28 \o/ thanks ralonsoh 14:05:01 haleyb: I'll ask and ping you 14:05:54 hmm we merged a few commits since rc1 14:05:55 mlavalle: ack. i just pushed reviews to tag rocky/queens/pike - https://review.openstack.org/#/c/651234/ https://review.openstack.org/#/c/651235/ https://review.openstack.org/#/c/651236/ - think pike will need an update 14:06:37 With that, we should focus on the PTG 14:06:44 hi 14:07:07 o/ 14:07:19 I remind the team that we are collecting topics in the etherpad: https://etherpad.openstack.org/p/openstack-networking-train-ptg 14:07:19 yes just 3 weeks and a day until the PTG starts if I'm not mistaken 14:07:37 yes, recently stable branches have backported many patches. 14:08:22 (after looking at the log) perhaps we need to cut a stable/stein update release soon after the stein release. 14:08:53 amotoki: yeah that's what I think we are going to do 14:09:28 This week I am going to start organizing the topics in the PTG etherpad in sessions 14:09:30 sounds good 14:09:40 so we have an agenda for the PTG 14:10:53 and I see we have 16 people confirmed to attend our social event on May 3rd. So it is going to be a fun dinner \o/ 14:10:56 regarding the stable branches, I also remind http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004594.html (pike extended maintenance). 14:11:20 amotoki: I added a topic to the on demand agenda to talk about that 14:11:20 we still do not mark ocata as EM. Pike is a newcommer 14:11:52 let's discuss it later or in the next meeting :) 14:12:11 any other announcements? 14:12:39 #topic Blueprints 14:13:19 The only thing that I want to mention in regards to blueprints is the openflow based DVR effort 14:14:09 https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr 14:14:29 This is the only blueprint that we targeted for Stein that we didn't complete 14:14:59 The plan that we have discused in the L3 subteam meetings is to merge this as early as possible in TRain 14:15:08 so we have time to debug it 14:15:39 Here's the series of patches: https://review.openstack.org/#/q/topic:openflow-based-dvr+(status:open+OR+status:merged) 14:16:07 Please help reviewing 14:16:19 I know tidwellr is already working on it. Thanks 14:16:48 I have one question about it 14:16:57 https://bugs.launchpad.net/neutron/+bug/1705536 is marked as rfe-postponed 14:16:58 Launchpad bug 1705536 in neutron "[RFE] L3-agent agent-mode dvr bridge." [Wishlist,Triaged] 14:17:03 should it be changed to approved? 14:17:54 slaweq: done 14:18:06 thx mlavalle :) 14:18:27 I wasn't sure if that was already discussed or not yet. Now it's clear :) 14:18:43 I think that might need to be reworded from Agent_Mode to Agent_Backend 14:19:03 I'll do that now 14:19:10 The other RFE that is approved and will start showing up in our reviews screen is https://bugs.launchpad.net/neutron/+bug/1764738 14:19:11 Launchpad bug 1764738 in neutron "routed provider networks limit to one host" [Wishlist,In progress] - Assigned to David Bingham (wwriverrat) 14:19:32 in my understanding rfe-postponed RFEs are approved but we fail to find persons who work on.... if we have volunteers we can move them to rfe-approved. 14:19:57 amotoki: yeap, we have people actively working on it 14:20:33 going back to 1764738, here's the wip patch: https://review.openstack.org/#/c/623115 14:20:58 it would be good if the team takes a look at it so we can have a fruitful discussion about it in Denver 14:21:12 amotoki: ok, thx. I didn't know that :) 14:22:34 This week also I will attend the StarlingX networking meeting. I know they are planning to propose blueprints for Train. So I'll make sure they add them to the PTG etherpad 14:23:01 any other blueprints we should discuss today? 14:24:05 mlavalle: is there any handy link? or can I find it in the openstack meeting page? 14:24:33 amotoki: link for what? 14:24:45 mlavalle: starlingX meeting 14:24:50 hang on 14:25:22 amotoki: https://wiki.openstack.org/wiki/Starlingx/Meetings#0615am_PDT_.2F_1415_UTC_-_Networking_Team_Call_.28Bi-weekly.29 14:25:47 thanks 14:25:47 it's a high bandwidth meeting in zoom 14:25:59 I still need to watch zoom log.. 14:26:35 cool 14:26:45 #topic Community goals 14:28:34 For python3 looking at the stadium jobs I plan on getting back to that once the stadium tempest plugin transition is done 14:28:50 thanks njohnston 14:29:03 I haven't followed the ML discussions; are the community goals for T set? 14:29:16 there was also an update in the ML on community goals for Train 14:29:18 http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004517.html 14:29:30 njohnston: you read my mind ;-) 14:30:09 regarding the community goals, we've done the WSGI goal, but we haven't switched to neutron-api with WSGI by default. we can make it as default in Train. 14:30:53 so it seems the community is talking about docs in PDF and IPv6 support for Train 14:30:53 amotoki: we should IMO first promote wsgi based ci jobs to be working in check and gate queues 14:31:04 Isn't WSGI by default a deployer decision that would be done in TripleO or something like that? 14:31:10 slaweq: totally agree 14:31:19 slaweq++ 14:31:35 for now it is only in experimental queue 14:31:46 neutron is the only project which hasn't switched it to WSGI in devstack 14:32:03 yeah, I think we should switch it 14:32:08 it would be a good follow-up :) 14:32:15 sorry I just joined, but are we expecting any hits to plugin projects as part of this? 14:32:44 boden: just in the initial conversation 14:32:54 nothing is imminent yet 14:32:55 sounds like a great goal for neutron train 14:33:09 eventlet dependencies might affect plugin projects. we can validate the impact in train 14:33:38 ack IMO it would be nice to give plugin teams a heads up so we can make sure the transisiton is smooth 14:34:04 boden: good feedback. Thanks! 14:34:33 we can even talk about it in Denver, while boden and other representatives of out of tree plugins are present 14:34:38 is that fair? 14:34:46 mlavalle++ 14:34:53 +1 14:35:02 +1 14:35:05 boden: do you want to add the topic to the etherpad? 14:35:18 mlavalle sure 14:35:31 cool 14:35:38 moving on 14:35:43 #topic Bugs 14:36:05 our deputy last week was bcafarel 14:36:12 here's the report: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004696.html 14:37:02 small update the in progress review for midonet failure was merged too (https://review.openstack.org/#/c/650599/) 14:37:52 so all the critial and high priority bugs have merged fixes, right? 14:38:17 mlavalle: indeed, all good for these sections! 14:39:56 so the two medium priority bugs lack owners 14:41:02 https://bugs.launchpad.net/neutron/+bug/1822591 14:41:03 Launchpad bug 1822591 in neutron "neutron-keepalived-state-change doesnt reap zombies if rootwrap-daemon is used" [Medium,Confirmed] 14:41:28 this one seems to be l3 ha dvr related 14:41:35 adding the tag 14:42:43 mlavalle: these zombies also happen on other agents (I tried with dhcp agent) 14:43:00 bcafarel: ack 14:43:03 apparently this behaviour appeared recently 14:43:05 https://bugs.launchpad.net/neutron/+bug/1823297 14:43:06 Launchpad bug 1823297 in neutron "create of segment range for vlan network type fails with error 500" [Low,Fix released] - Assigned to Slawek Kaplonski (slaweq) 14:43:20 I approved the fix for this one yesterday 14:43:25 thanks slaweq 14:43:33 this one was easy :) 14:43:46 bcafarel: anything else you wnat to highlight? 14:44:26 https://review.openstack.org/#/q/topic:bug/1811352+(status:open+OR+status:merged), I started the port forwarding OSC patches. 14:44:34 just a general reminder (I had forgotten), os-ken is in the list of projects using storyboard :) 14:44:44 https://bugs.launchpad.net/neutron/+bug/1811352 14:44:45 Launchpad bug 1811352 in neutron "[RFE] Include neutron CLI floatingip port-forwarding support" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 14:44:59 liuyulong: Thanks! 14:45:02 We've been missing this for too long. 14:45:07 so remember to redirect reporters there if you see open launchad bugs (thanks slaweq for reminding me) 14:45:23 bcafarel: thanks for the reminder 14:45:29 liuyulong: i am reviewing the osc change, will have comments soon 14:45:42 the deputy for this week is slaweq 14:45:45 haleyb, cool 14:45:59 and next week it will be hongbin 14:46:27 ok 14:46:32 I want to point out that this week we lost a member of the bugs deputy rotation 14:46:45 so I adjusted the schedule last night 14:46:46 I already started it this week :) 14:47:12 ah that's why I saw your name on recent bugs this week :) 14:47:29 bcafarel: yep :) 14:47:43 so for most of you, your duty week is going to be one week earlier than originally schedule 14:47:58 so pleae take a look and reconfirm your duty week 14:48:20 #topic neutron-lib 14:48:32 boden: you are up 14:48:34 hi 14:49:14 so for the most part I think we are waiting for Stein to officially go out the door before doing too much 14:49:32 once it does IMO it'd be nice to cut a new neutron-lib as there are some patches to consume 14:49:45 also I will refresh a number of consumption patches I've been holding off on 14:49:54 boden: let's plan to do that next week 14:50:02 ok 14:50:06 and that's about it 14:50:12 cool 14:50:16 thanks for the update 14:50:25 #topic On demand agenda 14:51:01 Back in January, we sent this message to the ML: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001383.html 14:51:54 smcginnis in the release team wanted to clarify that: "A stable branch enters extended maintenance after 18 months of initial release. It is not up to the project team to decide that" 14:52:19 so we are "bit late" with Ocata :) 14:52:42 we did the release mostly in time :) 14:52:46 and actually that conversation with me reminded him of sending http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004594.html 14:53:17 I am not sure what "extended maintenance phase" means in general. 14:53:35 https://review.openstack.org/#/c/650467/ will tag all last ocata releases as ocata-em (there will be another one soon for pike I suppose) 14:53:36 EM is a decision of each project team per document. 14:53:41 bcafarel: yes, he agrees on that. we did a good job. he was just concerned with clarifyin the semantics 14:54:10 amotoki: staying in EM is a decision of the project 14:54:37 but we get to EM at the 18 months mark regardless 14:54:38 mlavalle: ah, I see. EM or EOL is up to the project. 14:54:45 yep 14:54:51 hi, was eavesdropping so far :) for some detail about EM: https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life 14:55:17 this is the resolution about Extended Maintenance from last year 14:55:57 we seem to miss tagging on ocata in time. we need to tag last pike stable releases in time. 14:56:13 we can maintain a stable branch in EM as long as we are willing to actively work on it 14:56:28 also, smcginnis created a general patch for ocata: https://review.openstack.org/#/c/650467/ 14:56:47 but if nobody is working on it, then it is time to EOL 14:56:56 does this make sense? 14:57:20 mlavalle: makes sense to me 14:57:21 yes, that's it 14:57:48 that was my understanding (and yes makes sense) 14:58:09 * mlavalle had to be slapped twice by smcginnis befory getting this ;-) 14:58:23 one question from me is whether it is aware of plugin maintainers? 14:58:54 Hah. There was a lot of confusion around it. ;) 14:58:56 around ocata EM, what we struggled is how we coordinate all stadium projects. 14:59:26 in our case we should be careful in letting our eco-system know what is happening with stable branch 14:59:36 a consequence of our plugin architecture 15:00:04 ok guys, we ran out of time 15:00:09 thanks for attending 15:00:12 plugin is not the only eco-system we ahve thohgh..... 15:00:23 #endmeeting