14:00:46 #startmeeting networking 14:00:46 Meeting started Tue May 9 14:00:46 2023 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:46 The meeting name has been set to 'networking' 14:00:49 hello all 14:01:02 o/ 14:01:06 o/ 14:01:10 o/ 14:01:14 o/ 14:01:32 let's start 14:01:39 #topic announcements 14:01:40 o/ 14:01:47 #link https://releases.openstack.org/bobcat/schedule.html 14:02:00 we are finally in bobcat milestone 1 14:02:09 #link https://releases.openstack.org/bobcat/schedule.html#b-1 14:02:35 there are some patches related 14:02:38 #link https://review.opendev.org/c/openstack/releases/+/882599 14:03:05 and at the same time I'm releasing n-lib 3.6.0 14:03:08 #link https://review.opendev.org/c/openstack/releases/+/881231 14:03:17 so please check if something is missing and comment in the patches 14:03:20 and ping me please 14:03:37 Vancouer: https://etherpad.opendev.org/p/neutron-vancouver-2023 14:04:00 the forum proposal presented by slaweq was accepted 14:04:07 but it will take only 30 mins 14:04:30 this is because of the packed agenda during the 3 days the meeting will take 14:04:38 slaweq, can you add something there? 14:04:47 not much actually 14:04:55 on how we'll collect info and then prepare the PTG 14:05:03 we will have "meet and greet" session during forum 14:05:20 and as ralonsoh said - it's 30 minutes, as all other project related forum sessions 14:05:50 yatin proposed openstack/neutron-tempest-plugin master: Revert "Revert "Update nested-virt testing for the 2023.1 cycle"" https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/882719 14:06:10 I hope that will be enough to gather all the information from the users 14:06:23 it will be Tuesday morning so we will have time to prepare maybe some follow up agenda for PTG part which will be Wednesday and Thursday 14:06:24 that's our plan at least :) 14:07:24 ok, let's move to the next topic then 14:07:35 #topic bugs 14:07:48 the report from last week 14:07:51 #link https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033596.html 14:08:04 there are some bugs not assigned 14:08:06 #link https://bugs.launchpad.net/neutron/+bug/2018474 14:08:12 Unnecessary agent resource version 14:08:32 this could be an optimization in the agent RPC communication 14:08:56 anyone willing to dig into this code, please check the description 14:09:08 the next one is 14:09:10 #link https://bugs.launchpad.net/neutron/+bug/2018599 14:09:14 Disable config option use_random_fully does not work 14:09:45 I still need to check that in the code 14:10:07 but if I'm not wrong, that was added in https://review.opendev.org/q/Idfe5e51007b9a3eaa48779cd01edbca2f586eee5 14:10:54 but I think the problem is more related to an upgrade/update procedure 14:11:06 where one of the nodes was not properly configured 14:11:26 ralonsoh: I'll look at 2018474 14:11:26 I'm not in favor of disabling a config option just because an update went wrong due to a config issue 14:11:34 mlavalle, thanks 14:12:00 so I'll comment in LP#2018599 but please feel free to do the same 14:12:19 if there are clashing opinions, we can always bring this topic to the drivers meeting 14:12:54 and that's all I have 14:13:03 something else you want to bring here?? 14:13:33 ok, let's move then 14:13:36 #topic specs 14:13:48 we have 2 active Neutron specs 14:13:51 #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open 14:13:58 #link https://review.opendev.org/c/openstack/neutron-specs/+/882151 14:14:02 ERSPAN for tap-as-a-service 14:14:42 that was discussed a couple of weeks ago 14:14:53 so please spend some time reviewing it 14:15:04 I'll review both this week 14:15:08 next one is 14:15:11 #link https://review.opendev.org/c/openstack/neutron-specs/+/882272 14:15:15 Port extension to create hardware offloaded ports 14:15:35 trivial feature, commented during the PTG and approved recently 14:15:55 the last one, from Nova, is 14:15:58 #link https://review.opendev.org/c/openstack/nova-specs/+/859290 14:15:59 the one about dvr on openflow surprises me a bit. did we discuss that one? 14:16:07 this is related to Napatech LinkVirt SmartNICs 14:16:19 mlavalle, no, this is not an active one 14:16:29 ahh, ok, good to know 14:16:41 thanks for the clarification 14:17:06 so about the Nova spec, we commented during the PTG that these guys want to support this NICs in Nova and Neutron 14:17:23 the Neutron code should be easy but the main concern is the testing part 14:17:52 i think this one is good enough from neutron pov, nova are waiting for you to +1, no? 14:17:57 so please check the spec, focus on the Neutron implementation and let's keep an eye on the external CI these folks are implementing (if I'm not wrong) 14:18:23 sahid, to be honest, I didn't have a minute in the last 2 weeks to review it 14:18:43 so this is in my TODO list for tomorrow morning (and lajoskatona's one) 14:19:01 ++ 14:19:19 in any case, I don't provide any approval, that should became from Neutron cores 14:19:33 being PTL doesn't provide me any tech improvement 14:20:13 ok, I think that's all in this topic 14:20:22 something else you want to discuss here? 14:20:50 ok, let's move 14:21:06 #topic community_goals 14:21:12 1) sRBAC 14:21:23 we have some patches to be reviewed 14:21:32 related to qos and fips 14:21:38 I still need to verify qos one 14:21:44 why one test is failing there 14:22:02 yeah, I commented in the patch 14:22:08 thx 14:22:18 the list of patches is 14:22:20 #link https://review.opendev.org/c/openstack/neutron/+/882688 14:22:28 #link https://review.opendev.org/c/openstack/neutron/+/882414 14:22:35 and I would also like to thanks ccamposr who is doing great job with testing of this RBACs in our d/s product 14:22:37 #link https://review.opendev.org/c/openstack/neutron/+/882691 14:22:47 for sure! good catch 14:22:49 and he's the one who is finding all those small issues :) 14:23:10 slaweq, apart from this bug, what about enabling by default sRBAC? 14:23:21 it's enabled 14:23:31 last week we merged https://review.opendev.org/c/openstack/neutron/+/879827 14:24:16 we also merged https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879828 to change our ci jobs 14:24:17 but then gmann proposed revert of this change 14:24:18 Ihttps://review.opendev.org/c/openstack/neutron-tempest-plugin/+/882518 14:24:25 I'm talking about this patch 14:24:40 but main part is done - neutron by default is now using new policies 14:25:25 yes but why this revert? 14:25:39 just to make this public 14:26:15 so after https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879828 was merged, I though that we will use new defaults in all jobs and old defaults in one specific job 14:26:42 but it seems that it's not true and devstack was setting enforce_new_defaults=False explicitly in all jobs 14:27:02 so when will update the devstack flag? 14:27:06 so gmann reverted it and we still have only one job which is testing new defaults 14:27:51 I think it will be in 2024.1 cycle 14:28:05 perfect, so next release 14:28:09 that's what gmann wrote in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/882518 14:28:29 in any case, as you mentioned, we are already testing that in our CI 14:28:39 yes 14:28:46 that's for the time spent on this 14:29:05 ah, once merged (the 3 mentioned patches) we'll need to backport them 14:29:15 yes, up to stable/zed 14:29:20 thanks 14:29:21 I will do it for sure 14:29:54 lajos is not here today so we'll skip the neutron client migration 14:30:00 but I would like to add a new topic here 14:30:13 2) Ubuntu Jammy migration 14:30:38 ykarel, do you have any update related to the vexxhost issues? 14:30:49 #link https://bugs.launchpad.net/neutron/+bug/2017992 14:30:58 ralonsoh, no last update was technical team looking into the issue 14:31:16 but you are pushing again https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/882719 14:31:29 (we have these nodes disabled, I know) 14:31:32 yes pushed today and that should be ok to move with 14:31:43 perfect then 14:32:06 so are we moving the py310 during this release? 14:32:12 or that will be postponed 14:32:26 moving to* 14:33:24 aren't we already doing that? 14:33:44 not for us, we are still running in focal (py38) 14:34:04 so one of the reasons to move to jammy is to use py310 14:34:05 ok ok i meant non tempest jobs 14:34:42 so yes we can say moving to jammy this release for rest jobs 14:34:47 yes, we do 14:34:53 only tempest is missing 14:35:39 ok so I'll keep an eye on https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/882719 14:35:50 ^^ and anyone else 14:36:03 there are some other patches to allow running jobs in non nested nodes https://review.opendev.org/q/topic:libvirt-tb-cache-size , which we can followup after ^ 14:36:04 this is important, we should not delay this migration 14:37:20 but the performance is terrible, right? 14:37:44 yes if compared to nested-virt nodes 14:38:32 ok, let's check first the virt nested nodes and your n-t-p patch 14:38:35 ykarel, thanks! 14:38:59 and that's all in this topic 14:39:05 #topic on_demand 14:39:12 something you want to comment? 14:39:56 please remember the CI meeting is in 20 mins, in this channel 14:40:00 see you in a while 14:40:06 #endmeeting