14:00:24 #startmeeting networking 14:00:24 Meeting started Tue May 31 14:00:24 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:24 The meeting name has been set to 'networking' 14:00:27 o/ 14:00:27 o/ 14:00:33 hi 14:00:38 hi 14:00:45 hi 14:00:55 hi 14:01:06 o/ 14:02:04 Let's start it :-) 14:02:12 #topic Announcements 14:02:12 hi 14:02:17 o/ 14:02:21 hi! 14:02:25 hi 14:02:26 The usual Zed schedule: https://releases.openstack.org/zed/schedule.html 14:02:54 And I repeat the release countdown mail for week R-19, May 23 - 27: http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028616.html 14:03:30 as this one was the last, and I treat this as stll actual 14:03:30 hi 14:04:15 for relase things, please keep an eye on create EOL tags for neutron-vpnaas: #link https://review.opendev.org/c/openstack/releases/+/843167 14:04:35 It's actually hanging because Dmitriy Rabotyagov ( noonedeadpunk ) asked to keep Victoria alive 14:05:06 and elodilles asked to double check old legacy jobs and delete them before eoling any branch 14:06:16 I would like to ask your opinion before sending out mail about EOL queens, rocky, stein branches for stadiums 14:07:00 I have no objection 14:07:01 as far as I remember these branches for stadium were *really* quiet for a while already 14:07:03 as neutron-dynamic-routing already closed perhaps till train, and vpnaas is on its way to EOL also some branch 14:07:49 bcafarel: exactly and perhaps we can safe some CPU cycles with the deletion of those old periodic jobs 14:07:58 if we have any for them 14:08:06 +1 14:08:08 +1 from me 14:08:13 ok, thanks 14:08:21 +1 also asking for EOL sounds good we will see if there is any interest for these branches 14:08:22 I will send out mails about it 14:08:33 +1 14:08:49 +1 14:08:59 +1 14:09:16 Next announcement: 14:09:22 Propose Yatin Karel, ykarel for Neutron core team 14:09:28 http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028659.html 14:10:12 I close the voting and welcome ykarel in the team:-) 14:10:15 ykarel congrats! 14:10:21 congratulations ykarel!!! 14:10:31 ykarel: congrats 14:10:36 congrats to the new core team member. Welcome! 14:10:42 congratulations ykarel! 14:10:43 ykarel: thanks for your help with keeping things running :-) 14:10:54 ykarel congrats! 14:11:07 Thanks all \o/ 14:11:22 welcome ykarel! 14:12:31 Is there any questions, comments for announcements? 14:12:53 then let's move on 14:13:15 #topic Bugs 14:13:22 Report from bcafarel: #link http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028738.html 14:13:49 I saw perhaps 2 without owner: 14:13:58 Neutron RBAC not sharing subnet - #link https://bugs.launchpad.net/neutron/+bug/1975603 14:15:08 this one has potential fix at https://review.opendev.org/c/openstack/neutron/+/843871 but needs review (amorin noted it may re-introduce old bug) 14:15:49 TBH for me it's not even a bug but more like improvement 14:15:52 The question is something like this: I have a router from tenant A, and a subnet on a shared (with network rbac API) net from tenant B, if I try to add the subnet to router it fails 14:16:00 as we never said that subnets are supported by RBAC 14:16:13 slaweq, subnets should mimic the network RBAC 14:16:25 but yes, this should be consider an improvement 14:16:42 ralonsoh: yeah that was my first idea also, but I feel gaps which I don't see exactly here :-) 14:16:44 I think the workaround is to create a port in the shared subnet and then add it to a router. 14:16:59 the difference is a gateway is used or not. 14:17:01 I think it's similar to what we have with SG and SG rules 14:17:09 amotoki: sounds interesting 14:17:11 it's similar problem 14:17:23 ^^ right 14:17:53 so make net / subnets behavior parallel to sg / sg rules as far as rbac 14:18:25 I will check this workaround and discuss it with amorin and check how sg sg rule sharing works to see the difference 14:18:39 but I agree to have both work the same way 14:19:09 ok, thanks I check it with amorin and check it more 14:19:11 maybe continue the conersation in amorin's patch? 14:19:46 mlavalle: sure I will check that also (I just seen that amorin pushed a patch) 14:19:57 I want to know what happens :-) 14:20:25 mlavalle: :-) being informed is important 14:21:27 The next bug which I found: 14:21:30 difference in execution time between admin/non-admin call - #link https://bugs.launchpad.net/neutron/+bug/1975828 14:22:06 this is let's say the 2nd part of https://bugs.launchpad.net/neutron/+bug/1973349 (Slow queries after upgrade to Xena ) 14:22:36 I still need to reproduce it and check why is this happening 14:22:48 the first part is solved 14:23:08 ralonsoh: thanks, yes I was looking for the patch for it 14:23:14 https://review.opendev.org/c/openstack/neutron/+/841761 14:23:14 thanks for checking it 14:23:25 is this latest bug with master? 14:23:40 no idea, I still need to check it 14:24:16 mlavalle: the original bug was reported for Xena 14:25:20 yeah, I realize that, but this latter bug doesn't specify 14:25:56 mlavalle: my mistake, I just blindly copy-pasted the 2nd question from the original one 14:26:08 ok, I will assume Xena 14:26:27 let's move on 14:26:35 bcafarel: is there anything more to discuss from last week's bugs? 14:26:57 lajoskatona: all good I had the same 2 bugs in my "to mention" list - others have patches merged or well in the review process 14:27:01 yatin proposed openstack/neutron master: [DNM][FT] debug logs https://review.opendev.org/c/openstack/neutron/+/843791 14:27:14 bcafarel: thanks, sounds good 14:27:31 ok, let's move 14:27:34 This week haleyb is the deputy and next week amotoki will be. 14:27:49 amotoki: is that works for you? 14:27:50 lajoskatona: works for me 14:27:59 amotoki: ok, thanks :-) 14:28:33 #topic On Demand Agenda 14:28:47 Is there anything you would like to discuss? 14:28:55 i have one small thing 14:29:05 amotoki: please tell us 14:29:24 regarding vpnaas, mnaser proposed the removal of feature/lbaasv2. it is a part of branch cleanup 14:29:33 https://lists.openstack.org/pipermail/openstack-discuss/2022-May/028683.html 14:29:51 it looks fine to drop the branch without tagging the head 14:29:58 as it was covered by the corresponding branch in the neutron repo completely (as already mentioned in the ML thread). 14:30:10 I would like to double check it here in our meeting 14:30:28 thought? 14:30:36 amotoki: good that you mentioned it. thanks 14:31:22 I just checked your comments, and your memories looks correct, it really looks like it was a step to cut out fwaas 14:31:42 lajoskatona: exactly 14:32:21 we applied the same process when we split out advanced services. it is true for vpnaas, fwaas, lbaas and dynamic-routing 14:32:22 this week when I checked other stadiums found similar branches so I have to double check, and perhaps we can remove those also, I will mention them in the mail for EOL-ing old branches 14:32:57 lajoskatona: +1 14:34:06 if there's no more topics we can close for today 14:34:10 #link https://review.opendev.org/q/topic:packet_rate_limit Hi guys, request for review again, it is fine to get in now. Thank you for your time. : ) 14:34:41 liuyulong: welcome, I will check again for sure the hanging ones 14:35:04 New features with no harm to existing code, so it is safe to get merged. 14:35:23 lajoskatona, Thank you. : ) 14:37:03 Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix Load balancer remains on PENDING_CREATE https://review.opendev.org/c/openstack/ovn-octavia-provider/+/844059 14:37:16 Let's save ~23 minutes then:-) 14:37:21 \o/ 14:37:22 #endmeeting