14:00:23 #startmeeting networking 14:00:23 Meeting started Tue Mar 7 14:00:23 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:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 The meeting name has been set to 'networking' 14:00:24 hello all 14:00:33 o/ 14:00:37 o/ 14:00:39 o/ 14:00:39 hi! 14:00:44 o/ 14:00:59 o/ 14:01:03 o/ 14:01:09 let's start! 14:01:13 #topic announcements 14:01:27 as usual, during this important weeks 14:01:29 #link https://releases.openstack.org/antelope/schedule.html 14:01:44 this week is the final release for the non-client libraries 14:01:46 o/ 14:02:01 sorry, no! 14:02:12 (what I'm reading?) 14:02:29 next week is the final week for the RC 14:02:38 \o 14:02:39 so far, nothing went wrong during the last week 14:03:00 when we merged the releases for all the Neutron related projects 14:03:20 Cool 14:03:21 reno generation is still a bit broken, but a fix is in the works 14:03:27 but please, keep an eye on the CI and launchpad 14:03:30 frickler, which one? 14:03:55 2023.1 sorts before zed and everything else, leading to duplicated entries 14:04:02 ah yes yes 14:04:11 but seems to be addressed now 14:04:13 https://review.opendev.org/c/openstack/reno/+/876581 is the proposed fix 14:04:29 yeah and almost merged, so cool 14:05:03 ah, I almost forgot, last week we had the "election" polling (there wasn't for Neutron as I was the only candidate) 14:05:13 so you'll have me again for the next 6 months 14:05:16 sorry for you! 14:05:28 congratulations here's to 6 more months :) 14:05:41 lucky us! congrats :) 14:05:49 +2 14:05:54 thank you, congrats! 14:06:07 and please, remember the PTG is very very close 14:06:17 and we have a not-so-active etherpad 14:06:21 #link https://etherpad.opendev.org/p/neutron-bobcat-ptg 14:06:41 next week I'll add all related to sqlalchemy, neutronclient and CI 14:07:05 but if you have new features/RFE/bugs, please add them in this etherpad 14:07:23 (I'll send another reminder today) 14:07:30 something else here?? 14:07:50 just a stable service announcement, now that we have antelope branched 14:08:05 remember to also cherry-pick to this branch when doing a series of backports :) 14:08:08 right, 2023.1 14:08:31 (^^^ please don't make my mistake again: antelope is officially called 2023.1 in the code) 14:08:50 yeah be careful as this breaks alphabetical order :-) 14:09:30 btw, about this, I tested the patches renaming the DB branches 14:09:57 luckily the db migration tool only checks the migration IDs, not the directories 14:10:25 ok, let's move to the next topic 14:10:27 #topic bugs 14:10:35 It was my week 14:10:42 exactly 14:10:44 there is the report 14:10:46 #link https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032577.html 14:10:52 thanks 14:11:04 many bugs but most of them addressed or assigned under investigation 14:11:12 (thanks for this active community!) 14:11:17 There was only one which has no owner: https://bugs.launchpad.net/neutron/+bug/2009043 14:11:20 there are still 3 bugs to be discussed 14:11:24 yeah, this is the first one 14:11:42 actually the reporter just come back with some result what is the suspicion from their side 14:11:51 maybe slaweq could check that 14:11:54 if you have time 14:12:13 and I would like to as slaweq (or anybody more HA router knowledge) to check 14:12:33 sure, I will try to check it this week 14:12:37 thanks a lot 14:12:51 yes the reporter wrote that for them this patch is suspicios: https://review.opendev.org/c/openstack/neutron/+/776423 14:12:57 slaweq: thanks 14:13:19 the next one is 14:13:20 thats all from the bugs of last week, all other bugs are active 14:13:26 #link https://bugs.launchpad.net/neutron/+bug/2008858 14:13:50 I would like you to check this one because the cause (and the fix proposed) are not solving the reported issue 14:14:04 what is failing there is the Neutron DB access, not the OVN connectivity 14:14:05 ohh, I set it to inactive as there was no answer, but it is active again, thanks 14:14:58 ok, thanks ralonsoh 14:15:17 I'll check it today but my opinion is the same: in this bug the problem is the DB access, not the OVN connection. This timeout will make things worst 14:15:39 the last one in this list is 14:15:44 #link https://bugs.launchpad.net/neutron/+bug/2008808 14:15:54 but seems inactive since the report 14:16:05 to be honest, I don't know how to replicate this 14:16:14 did you have this problem before? 14:17:31 ok, we'll wait for more info 14:17:45 that's all from this list 14:17:50 This week slaweq is the deputy, next week will be haleyb 14:17:55 sure 14:18:11 that works 14:18:24 cool, thanks both 14:18:44 let's move to the next topic 14:18:50 #community_goals 14:18:57 1) Consistent and Secure Default RBAC 14:19:11 we have an active n-t-p patch 14:19:13 #link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/874709 14:19:18 with all the dependencies merged 14:19:33 but seems that this job "neutron-tempest-plugin-openvswitch-enforce-scope-new-defaults" is failing 14:19:36 I need to check why it's still failing 14:19:47 no rush and thanks 14:19:48 maybe we have missing something in neutron-lib, idk for now 14:20:18 I will ping You once it will be ready to review 14:20:28 sure, remember that we'll need that too in Zed 14:21:04 actually what is failing is zed job 14:21:06 yeah, in master it works fine, there is something missing in Zed just 14:21:07 not master one 14:21:37 in master I will work in this new cycle on the service role for communication between services 14:21:55 and on making new policies to be enabled by default 14:22:16 that is already agreed with nova for example? 14:22:26 qq, the service role will be available only in Bobcat, right? 14:22:26 lajoskatona what? 14:22:42 ralonsoh yes, I don't plan to backport it 14:22:48 I mean how the service role will be used for service-to-service comm 14:23:00 it's agreed generally 14:23:28 we need to identify what calls may be only for service2service and will be available by this new role 14:23:54 ok, thanks 14:24:05 admin role is too much and IIRC we agreed to use the service role for such communicatins. 14:24:26 yeah, this is not trivial to make a list of all S2S calls 14:24:37 do we need to sit down with nova team to clarify the deatils or it will be enough to do the reviews? 14:24:54 I think it will be enough to do reviews 14:25:00 because Nova is our client, they mostly should provide this info 14:25:13 but we can have a cross session during the next ptg 14:25:14 or if needed, I will add topic to the PTG to talk about that 14:25:15 to sync that 14:25:19 but need to check it first 14:25:19 correct 14:25:38 slaweq, will you ping Nova folks about this? 14:25:49 to know if they will be ready for this during the PTG 14:25:52 ralonsoh sure, if needed I will :) 14:25:58 perfect 14:26:14 thanks again for taking care of this 14:26:42 let's move then 14:26:46 2) Neutron client deprecation 14:26:52 the agenda: https://etherpad.opendev.org/p/python-neutronclient_deprecation 14:27:04 lajoskatona, something new? 14:27:17 I think no news 14:27:23 the usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation 14:27:45 I have to come back and push my patches as the last ones are still WIPs 14:28:15 during the next PTG I'll add a topic for this, mostly to make it public, see what is the progress and to try to involve more people on this 14:28:26 I already added :-) 14:28:36 right, i see it 14:28:39 I will add some details, I just added a line for it 14:28:41 perfect 14:29:17 we don't have a hard schedule, but let's see if during the next cycle we can deprecate nclient 14:29:24 the whole project 14:29:31 ok 14:30:05 and that's all in this topic 14:30:09 let's move to the last one 14:30:11 didn't we want to keep it as osc-plugin? 14:30:30 the plan is to move everything to sdk 14:30:38 and use the OSC, instead of the nclient 14:30:39 sdk is only one half 14:30:39 we want, but we can remove the python binding code 14:31:10 but we can discuss at the ptg. just invite gtema to that session 14:31:22 perfect 14:31:25 I think we need moree discussion on osc-plugin from neutronclient 14:31:31 frickler: right 14:31:45 frickler: good idea, I ask gtema f he can join 14:31:53 our current target is python bindings 14:32:23 right, that is undisputed afaict 14:33:18 in the patches which are up for this topic I kept the CLI code in neutronclient, but change to use sdk and not neutronclient binding code 14:33:35 I think we can have this conversation in the PTG, but is there any limitation to move all the bindings to SDK? 14:33:40 +1 14:34:07 even if that is finished, you still cannot deprecate the OSC-plugin part 14:34:24 no of course 14:34:49 o.k., maybe I misunderstood "deprecate nclient" then 14:34:51 but we'll stop doing anything in nclient, that at least is a good goal 14:35:36 frickler: no worries. neutronclient has two parts: CLI and python bindings, and it is always confusing :p 14:36:11 well if there happened to be a new feature in n-d-r for example that would require client support, that still would be added to nclient, wouldn't it? 14:36:16 actually what was supposedly deprecated (the CLI) can't be yet removed 14:36:48 well that's the point lajoskatona job here 14:36:52 ralonsoh: "neutron" CLI was deprecated but OSC plugin is still active I think 14:37:02 amotoki, right 14:37:38 if n-d-r is still using nclient, it should move to OSC 14:37:54 we should avoid any new develpment in nclient 14:38:20 all the "openstack bgp ..." commands are in nclient as osc-plugin 14:38:32 n-d-r support is now implemented as OSC plugin (not in OSC). 14:38:33 and there are no current plans to change that, or are there? 14:38:59 I think we said that no plan for that 14:39:11 and let's keep the repos as OSC plugin 14:39:15 perhaps what we first need to do is that OSC plugin for n-d-r consume openstacksdk instead of neutronclient python bindings 14:39:19 I mean neutronclient repo 14:39:42 amotoki: exactly, that's what I started 14:39:46 amotoki: that is what lajoskatona is working on I think, first moving the sdk code to openstacksdk repo 14:39:59 yes 14:40:38 at least we still need to add CLI commands to neutronclient OSC plugin 14:41:05 if we would like to add new commands related to n-d-r, right? 14:41:28 that's my understanding, yes 14:41:40 and why not spend time first on moving all the bindings to SDK and use the OSC in n-d-r? 14:41:58 we'll never finish the migration doing that 14:42:01 yes but we have only one SDK for all these when it is finished 14:42:12 +1 14:42:19 the commands are implemented in neutronclient, not in n-d-r 14:43:01 I can double check if n-d-r uses bindings from neutronclient somewhere 14:43:26 anyway the ptg session would be helpful to share the current situation and futures :-) 14:43:39 the discussion here is a good example 14:44:00 from a quick look n-d-r only uses rpc client 14:44:35 yes, let's go on and defer to PTG 14:45:35 ok, let's move on 14:45:54 #topic on_demand_agenda 14:46:13 I've been asked to release new versions for stable releases 14:46:19 X, Y and Z 14:46:31 U as well? 14:46:37 and that makes sense as we haven't done it for a long time 14:46:39 not U 14:46:55 let me check the state of U 14:47:23 Isn't U in EM phase already? 14:47:32 there have been some merges recently, one of which i'm interested in releasing 14:47:40 yes i do see the -em tag there 14:47:41 yeah, is in EM mode 14:47:56 could that also become a regular topic? weekly is likely too often, but e.g. in kolla we do a monthly check whether stable releases should be done 14:48:10 I'll add it to the agenda 14:48:24 I'll check if we can push a new hash for EM branches 14:48:29 and how 14:48:40 em gets no new tags 14:49:03 so that could be a problem then 14:49:04 it is consumed only from stable/ussuri or whatever head 14:49:16 yes 14:49:24 why? i'm probably just forgetting 14:49:26 what I mean is if we can update the EM hash? 14:49:49 what is "the EM hash"? move the ussuri-em tag: nope 14:50:22 yeah so the only next tag that a EM branch can have is EOL 14:50:25 right? 14:50:29 yes 14:50:43 thats my undertsanding also, the tag is set to some hash and it cant be moved 14:50:44 and that also drops the branch 14:50:46 haleyb, so no, we can't release any new version for W and older 14:51:11 Merged openstack/neutron master: Add full support for OVN NB "Gateway_Chassis" table https://review.opendev.org/c/openstack/neutron/+/874767 14:51:32 about Z, Y and X, I think you are ok with this, right? 14:51:34 ralonsoh: ack, i'll ask our downstream team about it 14:52:10 i'm fine with releasing everything else, yes 14:52:31 agree for new release 14:52:54 ok, I'll push the patches this week and I'll add all of you as reviewers 14:53:20 thanks 14:53:22 semi-related: is someone working on creating n-t-p zuul.d/2023.1_jobs.yaml ? 14:53:41 not yet, I think (let me check) 14:53:58 I didn't see a review at least 14:54:12 no, I'll do it too this week 14:54:17 I can check it 14:54:54 btw, I almost forget 14:55:06 related to the stable releases 14:55:07 Merged openstack/neutron stable/yoga: Reintroduce agent bridge resync test https://review.opendev.org/c/openstack/neutron/+/876464 14:55:14 I'll add the rest of the projects too 14:56:11 ok, so that's all for today, do you have something else? 14:56:36 thank you all and remember that today there isn't CI meeting 14:56:45 #endmeeting