21:00:28 <slaweq> #startmeeting networking
21:00:29 <openstack> Meeting started Mon May 11 21:00:28 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:32 <openstack> The meeting name has been set to 'networking'
21:00:37 <njohnston> o/
21:00:58 <haleyb> hi
21:01:33 <slaweq> hi
21:02:27 <slaweq> lets wait few more minutes for more people, like mlavalle and (maybe) bcafarel
21:02:34 <slaweq> or amotoki :)
21:04:25 <slaweq> ok, lets start
21:04:37 <slaweq> #topic Announcements
21:04:52 <slaweq> it's Ussuri GA week!
21:05:01 <njohnston> \o/
21:05:02 <slaweq> thx everyone involved in that release
21:05:34 <slaweq> it was great work and big pleasure to lead this team during this cycle :)
21:06:02 <slaweq> community plans some virtual celebration, if You want to join, details are in http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014781.html
21:06:25 <slaweq> this week there will be also community meeting where various people will highlight teams' achivements in Ussuri: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014646.html
21:07:26 <slaweq> next one
21:07:28 <slaweq> Victoria PTG planning etherpad: https://etherpad.openstack.org/p/neutron-victoria-ptg
21:07:44 <slaweq> it's only few weeks left to the PTG
21:07:56 <slaweq> so please add Your topics to the etherpad
21:08:16 <slaweq> Registration for the PTG is live (and free): http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014649.html
21:08:43 <slaweq> and the last announcement from me
21:08:45 <slaweq> Virtual OpenDev http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014297.html
21:08:59 <slaweq> anything else You want to announce to the team today?
21:10:58 <slaweq> ok, I take it as "no"
21:11:03 <slaweq> so next topic
21:11:09 <slaweq> #topic Blueprints
21:11:28 <slaweq> I did some initial plan for Victoria-1
21:11:33 <slaweq> https://launchpad.net/neutron/+milestone/victoria-1
21:11:56 <slaweq> please check this list and tell me if I missed any BP which You would like to work on/think that it should be on that list
21:12:08 <slaweq> or maybe I should remove something from this list
21:14:51 <njohnston> no feedback at this point
21:15:01 <njohnston> thanks to mlavalle for his super strong contribution
21:16:04 <slaweq> thx njohnston
21:16:29 <slaweq> there are also 2 BPs which I didn't plan for Victoria as I don't think we have resources and volunteers to implement them
21:16:30 <slaweq> https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host
21:16:32 <slaweq> and
21:16:36 <slaweq> https://blueprints.launchpad.net/neutron/+spec/neutron-classifier-neutron-qos
21:17:19 <slaweq> and that's all about BPs for this week from me
21:17:30 <slaweq> I guess that You don't have anything else to add, right?
21:18:02 <njohnston> correct :-)
21:18:56 <slaweq> ok, so next topic
21:19:02 <slaweq> #topic Community goals
21:19:13 <slaweq> any updates about zuul v3 njohnston ?
21:21:29 <njohnston> so with the advent of the zuul v3 grenade job
21:21:57 <njohnston> we had discussed 2 jobs:
21:22:20 <njohnston> a new OVN grenade job (slaweq)
21:22:43 <njohnston> and migrating the networking-odl grande jobs (lajoskatona).  This one is in progress https://review.opendev.org/#/c/725647/
21:22:44 <patchbot> patch 725647 - networking-odl - Migrate legacy grenade job to be native Zuul v3 - 4 patch sets
21:23:29 <slaweq> yes, I will propose patch for this OVN job migration this week
21:24:03 <njohnston> other than that, there is networking-midonet - perhaps now that the gate is fixed (thanks ralonsoh and slaweq!) progress can start there https://review.opendev.org/#/c/720788/
21:24:03 <patchbot> patch 720788 - networking-midonet - Make gate great again (MERGED) - 5 patch sets
21:24:55 <slaweq> and with those 2 we will be good, except networking-midonet, right?
21:24:59 <njohnston> I think that is it for zuulv3
21:25:14 <slaweq> ok, thx njohnston
21:26:08 <slaweq> I (still) don't have any updates about IPv6-only testing for our stadium projects
21:26:26 <slaweq> and with that, I think we can move on to the next topic
21:26:30 <slaweq> #topic Bugs
21:26:42 <slaweq> mlavalle was bug deputy; His report is at http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014794.html
21:27:05 <slaweq> it seems that there wasn't any high or urgent bugs last week
21:27:08 <slaweq> and that's good
21:27:13 <mlavalle> yeap
21:27:18 <slaweq> hi mlavalle :)
21:27:34 <slaweq> do You want to highlight some bugs from last week?
21:27:40 <mlavalle> yes
21:27:49 <mlavalle> I want to draw attention to https://bugs.launchpad.net/neutron/+bug/1877301
21:27:49 <openstack> Launchpad bug 1877301 in neutron "[RFE] L3 Router support ndp proxy" [Wishlist,Confirmed]
21:27:58 <mlavalle> I think it merits further discussion
21:28:50 <mlavalle> It comes from China and it is about further enabling Neutron in IPv6 deployments
21:29:12 <mlavalle> and we know Chinese deployers are being pushed to IPv6 only
21:29:22 <slaweq> thx mlavalle
21:29:38 <mlavalle> other than that, I think the rest is under control
21:29:44 <slaweq> I saw this one already and I wanted to ask haleyb and liuyulong to take a look and triage it
21:30:27 <mlavalle> it meybe especially meaningfiul to liuyulong
21:31:18 <slaweq> I saw also 2 bugs without assignments
21:31:21 <slaweq> https://bugs.launchpad.net/neutron/+bug/1877296
21:31:21 <openstack> Launchpad bug 1877296 in neutron "Tunnel ports are not cleaned up with several ovs agents restart" [Medium,New]
21:31:22 <slaweq> and
21:31:27 <slaweq> https://bugs.launchpad.net/neutron/+bug/1877254
21:31:28 <openstack> Launchpad bug 1877254 in neutron "neutron agent. list API lacks sort and page feature" [Medium,Triaged]
21:31:49 <slaweq> mlavalle: do you think that 1877254 can be marked as low-hanging-fruit maybe?
21:32:04 <slaweq> it seems for me that should be probably easy to fix, no?
21:32:14 <mlavalle> I think it would be pushing it a little bit
21:32:54 <mlavalle> maybe if we mark it low hanging fruit and clarify in the comments that whoever takes it can get help in the channel
21:33:19 <slaweq> sure, I can write such comment on it
21:33:20 <njohnston> +1 makes sense
21:33:46 <slaweq> and I will also take a quick look if there is maybe something obvious what we are missing or where to start looking for the issue
21:34:14 <mlavalle> I left pointers with previous work
21:34:38 <mlavalle> so whoever takes it can start from there
21:35:08 <slaweq> thx mlavalle
21:36:38 <slaweq> any other bugs You want to discuss today?
21:36:58 <mlavalle> nope
21:37:21 <njohnston> is this a good time to chat about https://bugs.launchpad.net/neutron/+bug/1878031
21:37:22 <openstack> Launchpad bug 1878031 in neutron " Unable to delete an instance | Conflict: Port [port-id] is currently a parent port for trunk [trunk-id]" [Undecided,New] - Assigned to Nate Johnston (nate-johnston)
21:37:52 <slaweq> njohnston: I think so :)
21:38:27 <njohnston> OK, so I have a general description of the issue at the top there; I just wanted to check with the experts in trunk ports to make sure I am not off-base with my solution proposal
21:39:43 <njohnston> in short: sometimes when an instance port is provisioned on a trunk, the port the instance is assigned is the parent port of the trunk.  When this happens the instance is not deletable because the port cannot be deleted, since it is the parent port of a trunk.
21:39:55 <njohnston> I propose that when a port is made parent port for a trunk, that the trunk be established as the owner of the port. That way it will be ineligible for instances seeking to bind to the port.
21:41:29 <slaweq> njohnston: and what in the "opposite direction" - so when port is already attached to the instance, we will need to block possibility to use it as trunk's parent port, right?
21:41:29 <njohnston> Any thoughts from trunk port experts?
21:42:17 <mlavalle> is slaweq a trunk expert?
21:42:31 <mlavalle> or you njohnston?
21:42:38 <njohnston> slaweq: That would make sense, but is probably lower priority.  You would have to intentionally make an instance port a trunk parent port, but we have people falling in to the issue in the bug without going out of their way to make it happen.
21:43:02 <slaweq> mlavalle: I'm definitely not trunk expert here
21:43:05 <njohnston> mlavalle: I have dabbled in it, but I think Bence or amotoki probably has more history with it than I do
21:43:36 <mlavalle> ok, let's finish this conversation and maybe loop back to the experts topic in the on demand agenda
21:44:20 <njohnston> ok
21:45:38 <slaweq> ok, our bug deputy this week is rubasov and he is already aware of it
21:46:01 <slaweq> I had to remove yamamoto from the list as he told me recently that he don't have enough time for triaging neutron bugs
21:46:21 <slaweq> #topic Neutron performance subteam
21:46:28 <slaweq> mlavalle: any updates on this one?
21:46:34 <mlavalle> no
21:46:42 <mlavalle> as I said I want to continue this
21:46:51 <mlavalle> but I couldn't do it last week
21:47:03 <mlavalle> I'll definitely pick it up in Victoria
21:47:09 <slaweq> ok
21:47:35 <slaweq> I will keep this topic in the meeting agenda for next months, is that ok for You?
21:47:52 <mlavalle> definetily
21:47:54 <mlavalle> thanks
21:48:04 <slaweq> thx
21:48:24 <slaweq> ok, that's all from me today
21:48:29 <slaweq> #topic On Demand Agenda
21:48:36 <slaweq> anything else You want to discuss today?
21:49:29 <njohnston> regarding the trunk port discussion, should this be converted to an ML topic so people can respond in their own timezone?
21:50:18 <mlavalle> I would say so
21:50:48 <njohnston> OK great, I will proceed with an email then
21:50:56 <slaweq> thx njohnston
21:51:03 <mlavalle> I want to say something about the "experts"
21:51:39 <mlavalle> when njohnston asked the experts on trumks, it hit me that we are not sure who is the definite expert on this topic
21:52:04 <mlavalle> and that led me to think that maybe in the PTG we should have a topic on experts realignment
21:52:26 <mlavalle> in other words, let's review our inventory of topics that we need experts on
21:52:36 <mlavalle> and see who is still alive in the community
21:52:47 <mlavalle> to cover those topics
21:52:54 <njohnston> good idea
21:52:57 <mlavalle> and fill in the gaps as needed
21:53:06 <slaweq> ++
21:53:15 <slaweq> and also review list of bug's tags on https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html
21:53:16 <mlavalle> once we discover a gap, we can request volunteers
21:53:22 <slaweq> as e.g. there is no "trunk" tag there
21:54:12 <mlavalle> and even if someone is not an expert on a topic, if a person volunteers for that topic, it means she / he will commits to become an expert in a reaonable ammount of time
21:54:26 <mlavalle> makes sense?
21:54:41 <njohnston> yes definitely
21:55:01 <slaweq> yes
21:55:10 <slaweq> mlavalle: can You add topic to the etherpad?
21:55:16 <mlavalle> I want to make sure we don't have gaping holes that might hurt us in the future
21:55:23 <mlavalle> slaweq: yes I'll add it
21:55:43 <slaweq> thx
21:55:54 <mlavalle> that's all I wanted to say
21:56:51 <slaweq> ok, I think that this is all for today
21:56:59 <njohnston> thanks all
21:57:00 <slaweq> thx for attending
21:57:06 <slaweq> and good night :)
21:57:08 <njohnston> o/
21:57:11 <slaweq> #endmeeting