14:00:27 #startmeeting networking 14:00:29 Meeting started Tue Jan 28 14:00:27 2020 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:31 hi 14:00:32 The meeting name has been set to 'networking' 14:00:50 o/ 14:00:52 o/ 14:00:57 hi 14:00:57 o/ 14:01:06 hi 14:01:14 o/ 14:01:29 hi 14:01:45 #topic Announcements 14:02:08 first releases related things 14:02:13 We are getting close to Ussuri-2, it will be in the week of February 10: https://releases.openstack.org/ussuri/schedule.html 14:02:39 so we should focus on reviewing patches related to BPs scheduled for Ussuri-2 (but we will get to BPs later) 14:02:57 We are also getting close to Rocky EM: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012207.html 14:04:09 so if You have any backports to rocky which You would like to be released, please reach out to our stable core team 14:05:18 and the last one (as a reminder) 14:05:28 we are still looking for maintainers for neutron-fwaas 14:05:44 last call mail was sent by me some time ago: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012099.html 14:06:13 but TBH I don't think we will have any volunteers to maintain it :/ 14:07:18 any other announcements from the team? 14:09:01 ok, I guess there is no other announcements from the team 14:09:12 #topic Blueprints 14:09:25 here are all BPs for U-2: https://launchpad.net/neutron/+milestone/ussuri-2 14:10:22 we may probably have problems with https://blueprints.launchpad.net/neutron/+spec/default-dns-zone-per-tenant as owner of it can't work on it anymore so we need new volunteer 14:11:10 I reached out to amorin from OVH to ask about it but he don't know if they will have anyone new to work on this soon, so probably we will need to postpone it for now 14:11:19 do You have any updates about other BPs? 14:11:53 mlavalle had an update he sent yesterday because he would not be able to attend, not sure if you saw it 14:12:10 bcafarel: I think I missed it 14:12:14 was it on ML? 14:12:15 "made good progress with tagging during create port bulk. The patch is good to go: https://review.opendev.org/#/c/700755, which now depends on https://review.opendev.org/#/c/704240" 14:12:16 patch 700755 - neutron - Implement tagging during bulk port creation - 12 patch sets 14:12:17 patch 704240 - neutron - Pass result dict to extensions by create port bulk - 3 patch sets 14:13:18 just good ol' IRC :) 14:13:26 ok, thx bcafarel :) 14:13:37 I saw he also set review priority for those patches 14:14:06 I will today or tomorrow go through list with other patches related to BPs for U-2 and will set priority for them too 14:14:34 so please check this review-prio list next days and review those patches :) 14:16:44 ok, so I guess there is no updates about other BPs for today 14:16:51 lets move on then 14:17:01 #topic Community goals 14:17:18 I still didn't had time to work on this PTL docs yet 14:17:29 njohnston: any updates about dropping py2 support? 14:17:53 The drop py27 goal appears to have been achieved, as far as I can tell 14:17:56 all changes have merged 14:18:07 we may find a few little leftovers here and there over time 14:18:23 so projects are now fine to make their code incompatible with py27: removing six, etc. 14:18:29 \o/ that's great news 14:18:41 thx njohnston for all work on that 14:18:43 cool! 14:18:48 thanks njohnston 14:19:07 I saw gmann sent a patch for neutron-tempest-plugin, we may have a few bits left there 14:19:10 we have great progress on the zuulv3 migration, which is going to be a goal for the V cycle 14:19:12 * bcafarel looking for review 14:19:21 I will mark this goal as done and will remove it from meeting's agenda 14:20:09 https://review.opendev.org/#/c/704257/ 14:20:10 patch 704257 - neutron-tempest-plugin - [ussuri][goal] Drop python 2.7 support and testing - 1 patch set 14:20:14 bcafarel: Yes I think I remember that, the branchless tempest plugins are in a little bit of an odd situation, and gmann has been great helping shepherd the whole QA infrastructure so it handles that 14:20:59 but our problem is only for rocky, right? 14:21:07 stein and newer already runs on py3 IIRC 14:21:14 right 14:21:15 #link https://review.opendev.org/#/c/704257/ 14:21:15 patch 704257 - neutron-tempest-plugin - [ussuri][goal] Drop python 2.7 support and testing - 1 patch set 14:21:32 i need to check rocky issue if that is same. 14:21:34 so it's problem only for few weeks 14:21:47 as we agreed some time ago to run tagged version of plugin on EM branches 14:21:55 and rocky will be EM in few weeks 14:22:09 hi gmann :) 14:22:25 to fix py2 things on rocky. we merged the running tempest on py3 venv - https://review.opendev.org/#/q/topic:bug/1860033+status:merged 14:22:32 so it should be fine. 14:22:53 the error for that change seems to be a requirements problem 14:22:54 Could not find a version that satisfies the requirement zipp===2.0.1 (from -c https://releases.openstack.org/constraints/upper/master (line 702)) (from versions: 0.1.0, 0.2.0, 0.2.1, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.4.0, 0.5.0, 0.5.1, 0.5.2, 0.6.0, 1.0.0, 1.1.0) 14:23:04 As of now it failed due to zipp in py2. zipp issue has been fixed I think 14:23:39 https://review.opendev.org/#/c/704263/ should fix it. 14:23:40 patch 704263 - requirements - Use zipp 1.1.0 for python 3.5 and lower (MERGED) - 1 patch set 14:23:42 yeah, it is fixed 14:24:12 recheck should work now as tempest patch is merged recently - https://review.opendev.org/#/c/703011/ 14:24:13 patch 703011 - tempest - Define python3 as basepython for Tempest tox env (MERGED) - 9 patch sets 14:25:36 ok, lets check this patch than 14:25:44 thx gmann for help with that 14:25:52 thanks gmann! 14:26:56 so lets move on to the next topic than 14:26:58 #topic Bugs 14:27:16 lajoskatona was on bug deputy 14:27:28 Yes 14:27:34 lajoskatona: any bugs You want to bring up for team's attention? 14:27:49 as I wrote in the summary I think it was a quiet week, mostly with CI related bugs 14:28:12 and some moving of old networking-ovn bugs to neutron launchpad folder 14:28:54 And as I remember perhaps one is not covered with somebody 14:29:24 https://bugs.launchpad.net/neutron/+bug/1860662 perhaps this one is without owner 14:29:24 Launchpad bug 1860662 in neutron "[OVN] FIP on OVN Load balancer doesn't work if member has FIP assigned on DVR setup" [Medium,New] 14:29:55 so I think that's it for bugs 14:30:39 Ohhh, perhaps 2 that can be good for drivers team, 14:30:57 https://bugs.launchpad.net/neutron/+bug/1860338 14:30:57 Launchpad bug 1860338 in neutron "[OVS] OVS agent should not plug/unplug smartNIC ports" [Wishlist,New] 14:31:08 yes, about this one 14:31:13 This one is related to recent smartnic support pathces 14:31:15 I also wanted to ask about it 14:31:28 this is a concern related to smart nics and OVS 14:31:48 OVS agent should take care of >=L2 events 14:31:51 not L1 14:32:06 that means: should not plug or unplug any interface 14:32:25 but I have a meeting this week with other RH and Mellanox guys 14:32:28 about this 14:32:37 so I'll add my comments in the bug 14:32:39 ralonsoh: but my first question here is: should we treat it as RFE or bug? 14:33:10 slaweq, I prefer to hear from Mellanox about smart nics and future developments 14:33:21 and the we (Neutron community) can decide about this 14:33:25 then* 14:33:44 ralonsoh: ok, please update LP with any additional info which You will have 14:33:48 sure 14:34:39 thx ralonsoh 14:34:43 The other one is this one: https://bugs.launchpad.net/neutron/+bug/1860521 14:34:43 Launchpad bug 1860521 in neutron "L2 pop notifications are not reliable" [Undecided,New] 14:34:59 that is already marked as RFE 14:35:33 That's really all of last week 14:35:41 regarding bugs 14:35:43 yes, I will take care of it to triage it 14:35:50 thx a lot lajoskatona 14:36:27 :-) 14:37:44 our bug deputy this week is tidwellr and he confirmed me by email that he will take care of it 14:38:22 and next week bug deputy will be Swami, I will ping him via email too 14:38:48 ok, I think we can move on 14:39:04 or do You have any bugs which You want to talk about now? 14:40:17 ok, so I think we can move on 14:40:22 #topic Networking OVN and ML2+OVS+DVR Convergence 14:41:01 I think lucasgomes isn't here now 14:41:29 one sec 14:41:59 ralonsoh: maybe You have any updates about it? 14:42:08 not all the info 14:42:17 we have some problems with the FT tests 14:42:23 there we go ^^ 14:42:23 * haleyb looks for the review topic 14:42:38 lucasagomes, hi, can you update the OVN migration status? 14:42:47 ralonsoh: hi there, yes 14:43:10 https://review.opendev.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/neutron-ovn-merge 14:43:14 so I think we are similar to last week, we have the ovn driver almost enterily merged but it's missing functional tests 14:43:31 that said, we needed a new version of ovsdbapp in order to have the FT to start to run 14:43:35 that's done 14:43:48 so now they r being executed and we need to take a look in a few tests that are failing 14:44:00 hopefully all will be sorted by this week 14:44:22 I also started migrating the bugs from the networking-ovn bug tracker to the neutron bug tracker 14:44:35 so don't freak out if u see a bunch of new bugs popping up for OVN there 14:44:45 I guess that's mostly it 14:45:07 not sure if mentioned last week... but, we now have an tempest OVN test running (voting) in the gate 14:45:14 thx lucasagomes 14:45:33 do You need to propose new ovsdbapp release? or are You still waiting for some patch to be merged there? 14:45:33 one related item, i've been working on getting an ipv6-only job working for OVN, think it's happy now 14:45:41 * haleyb waits 14:45:42 slaweq: it's been released already 14:45:48 and requirements have been bumped 14:45:55 lucasagomes: ok, great then 14:46:07 haleyb: sorry, go on :) 14:46:22 https://review.opendev.org/#/c/703685/ and https://review.opendev.org/#/c/700939/ just need a few reviews 14:46:23 patch 703685 - neutron - Fix OVN agent devstack script to support IPv6 - 3 patch sets 14:46:24 patch 700939 - neutron - Define new ipv6-only job for OVN - 10 patch sets 14:46:36 haleyb: awesome! Will take a look today at it 14:46:39 i like the patchbot 14:47:07 lucasagomes: thanks! 14:47:10 ah btw, to help with reviews I created a small OVN driver dashboard that filters out the reviewsing in neutron 14:47:12 if u interested: https://bit.ly/2voTVXf 14:47:34 * lucasagomes is off-topic 14:47:42 thanks lucasagomes 14:47:55 thx lucasagomes for the link 14:47:57 looks nice 14:48:16 and thx for update lucasagomes and haleyb 14:48:22 yw 14:49:14 ok, lets move on 14:49:18 #topic On Demand Agenda 14:49:23 we have one topic there: 14:49:31 "Do we need to change job definitions on stable branches as well?" 14:49:50 I'm not sure who added it, njohnston is it Yours? 14:49:56 It was me 14:50:01 ahh, ok 14:50:05 so go on lajoskatona :) 14:50:32 The question came from bagpipe or bgpvpn job changes to zuukv3 14:51:18 and the problem is that now some job definitions are in some common repo (job-configs or similar) and infra tend to ave the new jobs in porject repos 14:51:55 which I understand, but if we have one zuulv3 job definition in project repo, and old one somewhere else that can cause problems for maintenance 14:52:03 and cause confusion, etc... 14:52:33 In neutron repo we keept jobs for stable branches to be legacy ones 14:52:45 So my question is do we need to change old branches job definitions to zuulv3 (where possible) or let it as it is and care for multiple job definitions for the same job 14:52:56 so we didn't backport those patches which proposes zuulv3 jobs to stable branches 14:53:12 but we changed names of jobs 14:53:24 as old jobs has got "legacy" in name 14:53:34 ok, then that is clear, let the legacy jobs as they are 14:53:54 so we proposed new (zuulv3) jobs without this word "legacy" 14:53:54 thanks 14:54:09 but I'm open to any other ideas how to do this 14:54:21 Ok, I check my patches, 14:54:25 IMHO we can backport zuulv3 changes. It would reduce the maintenance cost especially in small projects. 14:54:52 slaweq: no, I am ok with it, In my mind I can argue fro both solutions, so I wanted to hear other opinions as well 14:55:56 I think the most important is to have a common agreement otherwise it will be more difficult :-) 14:56:29 hmm true we made sure that all new jobs get new names (even if close sometimes) 14:56:33 from my personal experience I can say that migrating to zuulv3 may not be as straight forward in some cases and doing it also for stable branches may be even harder, especially now with this all "dropping py2 support nightmare" :) 14:57:09 and maintenance of those jobs in stable branches is pretty minimal usually 14:57:20 salweq: yeah that is also one thing to consider, that it is time consuming to do the conversion 14:57:31 my main fear is that things go south when trying to backport new job definition - needed code changes somehow, not working on older branches, etc - but that should not blocking from attempting it :) 14:59:04 I would say: keep legacy jobs for stable branches, at least if it works fine, when such job will require some fixes, we can think about moving it to zuulv3 for stable branches then 14:59:18 I think it is better to have similar approach at least on networking projects, so all to change to v3 or let legacy to be legacy 14:59:50 ok, we are almost out of time now 14:59:56 Ok, for me it is ok, and I suppose acceptable for infra as well 14:59:56 thx for attending the meeting 15:00:04 #endmeeting