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