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