14:00:32 <haleyb> #startmeeting networking 14:00:32 <opendevmeet> Meeting started Tue Jan 14 14:00:32 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:32 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:32 <opendevmeet> The meeting name has been set to 'networking' 14:00:35 <ihrachys> o/ 14:00:39 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:40 <mlavalle> \o 14:00:51 <s3rj1k> hi all 14:00:56 <slaweq> o/ 14:01:04 <rubasov> o/ 14:01:06 <obondarev> o/ 14:01:18 <bcafarel> o/ 14:01:41 <haleyb> #announcements 14:01:57 <haleyb> hi everyone! 14:02:00 <lajoskatona> o/ 14:02:38 <haleyb> first, thanks for everyone that helped run meetings while i was out, i think i now have the energy to get through the cycle :) 14:03:07 * mlavalle will have to leave at 30 minutes after the hour 14:03:20 <haleyb> ack 14:03:32 <haleyb> We are currently in week R-11 14:03:37 <haleyb> #link https://releases.openstack.org/epoxy/schedule.html 14:03:43 <ralonsoh> hello 14:03:49 <haleyb> E-2 milestone was last week 14:04:35 <haleyb> i don't remember seeing a neutron release though i could have missed it 14:04:49 <haleyb> i did see neutron-lib 14:05:19 <slaweq> I didn't propose it for sure 14:05:21 <haleyb> slaweq: did i miss it? maybe you approved it 14:05:34 <haleyb> i thought there was some automation there 14:05:35 <slaweq> And I didn't saw it neither 14:06:12 <haleyb> i'll look into it 14:06:45 <frickler> eventlet is now bumped to the latest version https://review.opendev.org/c/openstack/requirements/+/933257 14:06:52 <haleyb> 'F' release naming (hopefully everyone voted) 14:06:56 <haleyb> 'Flamingo' is the code name for 2025.2 14:07:33 <haleyb> Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers 14:07:35 <mlavalle> nice 14:08:01 <haleyb> And of course a reminder to use the priorities dashboard for patches in the "ready to merge" state 14:09:40 <haleyb> I had sent a draft email to the other cores on Linuxbridge driver removal, thanks for the responses, i just haven't read them yet 14:10:03 <haleyb> i will send that email to the ML after this meeting hopefully 14:10:22 <haleyb> thanks to ihrachys for pushing the patch 14:10:43 <ihrachys> fixed the last fullstack issue there yesterday, should be green now (minus random issues in gate) https://review.opendev.org/c/openstack/neutron/+/927216 14:11:10 <haleyb> slaweq did have one question on the timeline - were we going to do it in the E cycle 14:11:11 <lajoskatona> thank you both for pushing this topic 14:12:26 <slaweq> I asked about it mostly because of the distros who are packaging Neutron as they will need to remove neutron-linuxbridge-agent binary 14:12:29 <ihrachys> afaiu the general rule is one cycle deprecated, then remove; in this case, it was not "deprecated" but it was "hidden behind a experimental flag with a huge warning that it sucks". whether these are the same is a subject for debate among friends. 14:13:03 <haleyb> ihrachys: i think you looked into the question ^^ and we should be doing it in a slurp ? but i don't remember 14:13:27 <slaweq> ihrachys that is correct, I am just not sure if we are not "too late" in the cycle as we already passed M-2 milestone 14:13:41 <haleyb> slaweq: i'm not sure we even package it any more, need to double-check 14:13:48 <ihrachys> if experimental >= deprecated in terms of abandonness / admin awareness of its badness, then we can do it any time I think 14:14:02 <slaweq> I think that RDO for example packages it 14:14:22 <ihrachys> are there rules that would not allow it in M2 vs M1? 14:14:45 <slaweq> I don't think there are rules about that regarding parts of the project 14:14:52 <slaweq> like in this case 14:15:40 <slaweq> haleyb RDO is for sure packaging it still: https://review.rdoproject.org/r/plugins/gitiles/openstack/neutron-distgit/+/refs/heads/rpm-master 14:16:04 <ihrachys> I can send a patch removing it in RDO, shouldn't be a problem, 10mins work 14:16:34 <ihrachys> my take is the only relevant determination as to whether we CAN do it is whether we equate deprecation to experimental. 14:16:46 <slaweq> regarding SLURP/non-SLURP release, I think we should be good to remove it in SLURP now as we already had it deprecated/experimental in the previous SLURP 14:16:48 <ihrachys> apart from it, it's a question whether we PREFER doing it now or later 14:16:52 <haleyb> ubuntu is packaging it as well, since it's automated and hasn't broken 14:17:54 <haleyb> ihrachys: right, is deprecation == experimental is the real question 14:18:08 <ihrachys> my answer to both is 1) we can since experimental >= deprecated; and 2) I prefer now because it's better to do it earlier and remove the burden from the code base (plus some personal reasons!) 14:18:12 <lajoskatona> +1 for doing it in SLURP 14:18:52 <haleyb> and i agree i think having it experimental means it can go away at any time 14:19:36 <haleyb> maybe i need to clarify in my email our plan for this cycle 14:20:02 <ihrachys> ok I guess some believe we should wait and some don't. we can vote or just let someone named Brian to make a call. I can do both really, not hard to rebase it for another two months. ultimately it's for the team to carry the maintenance of these code paths. 14:20:54 <ralonsoh> LB has been laying in the repository for too long, without any support 14:21:12 <haleyb> ihrachys: vote would be better, consensus is telling me people will vote removal 14:21:13 <ralonsoh> we already marked it as experimental because calling it "deprecated" implies not testing 14:21:30 <haleyb> and it is untested except for experimental 14:21:41 <ralonsoh> so removing it now is a logical action 14:21:51 <ralonsoh> (after 5 cycles as experimental) 14:21:57 <slaweq> I'm fine with removing it now, just wanted to be on safe side and ask just to make sure there are no any obvious problems with it 14:22:14 <ihrachys> slurp users will get it removed before next slurp anyway. they will skip Flamingo. 14:22:25 <slaweq> I (not formally) vote to go with it now but lets haleyb decide 14:22:34 <ihrachys> wait, I think I mixed release types. 14:22:46 <ihrachys> so next is slurp? then we are in agreement? 14:22:57 <ralonsoh> no, E is slurp (this one) 14:23:08 <slaweq> ihrachys 2025.1 will be slurp 14:23:14 <ihrachys> yeah ok, then I confused everyone and lajoskatona was also for removing it now. 14:23:32 <ralonsoh> so, as slaweq, I vote for removing it now 14:23:43 <ihrachys> LFG then! 14:24:06 <lajoskatona> +1 14:24:29 <haleyb> ok, i'll see what we get for reponses, and if there is some technical reason on wait until F 14:24:50 <mlavalle> +1 14:25:08 <haleyb> thanks for the discussion 14:25:31 <haleyb> i had no other announcements 14:26:07 <haleyb> #topic Bugs 14:26:18 <haleyb> last week ralonsoh was the deputy, his report is at 14:26:26 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GH4YANL6MFGMD4YGV6QAT2GU7EHWSZP6/ 14:26:54 <haleyb> there are two unassigned 14:27:09 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2093327 14:27:10 <ralonsoh> I'll take 2093327 14:27:15 <haleyb> sold! 14:27:37 <haleyb> that might be a bug in OVN? 14:27:43 <ralonsoh> I need to check with ovn/ovs folks what is happening there 14:27:46 <ralonsoh> maybe, yes 14:28:30 <haleyb> ack 14:28:36 <haleyb> the other one was a doc bug 14:28:40 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2093317 14:28:56 <haleyb> vpnaas documention 14:30:48 <haleyb> bpetermann: is that something you could look at? seems related to https://review.opendev.org/c/openstack/neutron-vpnaas/+/895651 14:31:00 * mlavalle dropping off 14:31:32 <lajoskatona> yes the documentation request is related to the OVN driver as I remember 14:31:37 <bpetermann> Yes, I can see what I can add to the documentation 14:31:59 <haleyb> bpetermann: thanks 14:32:17 <bpetermann> Regarding the auto-failover there's another bug ticket. It currently doesn't work because a missing OVN IDL access in the periodic worker 14:32:30 <ihrachys> I think we generate some web pages from oslo.config e.g. for neutron https://docs.openstack.org/neutron/pike/configuration/ml2-conf.html 14:32:53 <ihrachys> if not, vpnaas should do the same and then I guess there will be some "documentation" for the missing options. 14:33:23 <ihrachys> there is already https://docs.openstack.org/neutron-vpnaas/latest/configuration/index.html is it not enough? 14:33:49 <lajoskatona> bpetermann: this is the bug you refer I think: https://bugs.launchpad.net/neutron/+bug/2089250 14:33:54 <haleyb> ihrachys: yes, things are automated via some setup.cfg entries, assuming everything was added 14:34:18 <bpetermann> lajoskatona: yes 14:35:38 <lajoskatona> ihrachys: the cfg options in the bug report are not in the above docs, good question why 14:37:59 <ihrachys> they are not listed in neutron_vpnaas/opts.py probably 14:39:12 <haleyb> we can maybe figure it out in the context of the bug, could be something simple 14:39:19 <ihrachys> I'll send a patch for this in 15m 14:39:26 <haleyb> any other bugs to discuss? 14:39:44 <haleyb> lajoskatona is the deputy list week, ykarel will be next week 14:40:24 <lajoskatona> my eyes on launchpad 14:40:33 <haleyb> +1 14:40:37 <haleyb> ok, moving on 14:40:41 <haleyb> #topic community goals 14:40:56 <haleyb> lajoskatona: good progress on neutronclient deprecation 14:41:25 <haleyb> #link https://review.opendev.org/q/topic:%22bug/1999774%22 14:41:58 <lajoskatona> some progress at least :-) 14:42:04 <haleyb> i had some comments on the FIP one 14:42:20 <haleyb> they're in the review 14:42:50 <lajoskatona> haleyb: I saw, but had no time to go back this week, thanks for checking 14:42:58 <opendevreview> Ihar Hrachyshka proposed openstack/neutron-vpnaas master: Register VPN_AGENTS_SCHEDULER_OPTS in plugin config sample https://review.opendev.org/c/openstack/neutron-vpnaas/+/939246 14:43:22 <haleyb> lajoskatona: ack, keep up the good work :) 14:43:38 <lajoskatona> :-) 14:43:53 <haleyb> other goal is eventlet deprecation 14:44:02 <ralonsoh> yes, I have two main topics 14:44:03 <ralonsoh> https://review.opendev.org/q/topic:%22bug/2087943%22 14:44:08 <ralonsoh> L3 eventlet deprecation 14:44:25 <ralonsoh> the reviews: reducing the pool will slow down the processing 14:44:39 <ralonsoh> I'll provide a script, creating networks and routers connected to external network 14:44:45 <ralonsoh> and how to test it with both codes 14:44:52 <ralonsoh> there is no performance impact 14:45:12 <ralonsoh> apart from this, using threads won't provide more speed in the python code, same as in the dhcp agent 14:45:33 <ralonsoh> if we really want to improve the dhcp/l3 performance, we need to create some kind of multiprocessing agent 14:45:41 <ralonsoh> please check these patches 14:45:47 <ralonsoh> as I commented, I'll add this script 14:45:52 <ralonsoh> the second topic: the metadata 14:45:57 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/937545 14:46:01 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/938393 14:46:12 <ralonsoh> both the ovn metadata agent and the ovn agent 14:46:18 <ralonsoh> both tested ok in the CI 14:46:45 <ralonsoh> of course, as I documented: we lost the capability right now to spawn multiprocess metadata server 14:46:55 <ralonsoh> this can be implemented in a closer future 14:47:05 <ralonsoh> but right now, we need to remove eventlet 14:47:07 <ralonsoh> that's my update 14:47:59 <lajoskatona> thanks fo the update 14:48:12 <haleyb> ralonsoh: i saw the comments on L3 and thanks for digging into that issue - i will let the data drive any decision as i'm remembering from years ago the thread pool helped, but i was proven wrong with the dhcp-agent already 14:48:39 <opendevreview> Fernando Royo proposed openstack/ovn-octavia-provider master: Add LB sync logic https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925324 14:48:56 <ralonsoh> I'll provide a script to create several routers. Then, is just a matter of restarting the L3 agent and check the times 14:49:09 <ralonsoh> I have no performance impact (in my dev env, of course) 14:50:30 <haleyb> ralonsoh: and regarding the remaining pieces/bugs, i see 4 remaining, although the LB one should go away 14:50:33 <haleyb> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=eventlet-deprecation 14:50:53 <ralonsoh> OVS is being handled by sahid 14:50:58 <ralonsoh> we can remove the LB one 14:51:08 <ralonsoh> I'm testing right now the Neutron API 14:51:28 <ralonsoh> and the sriov agent, once we have a oslo.services release without eventlet, should be trivial 14:51:37 <haleyb> so that leaves dhcp-agent 14:51:48 <ralonsoh> ah, same comment 14:52:07 <ralonsoh> I already did some patches (maybe not related to this bug, because I didn't create it yet) 14:52:33 <ralonsoh> but (1) with the metadata server, (2) the oslo.services and (3) some minor methods, it will be ready 14:52:41 <ralonsoh> (I think so, I'm optimistic...) 14:52:58 <ralonsoh> in any case, the DHCP agent is widely tested in the CI 14:53:24 <ralonsoh> that's all 14:53:53 <haleyb> ack, let's focus in the next week at reviewing/merging what is proposed 14:54:41 <haleyb> thanks for the update 14:54:56 <haleyb> #topic on-demand 14:55:28 <haleyb> there was a topic from last week 14:56:00 <haleyb> merge of https://review.opendev.org/c/openstack/neutron/+/936235 without two +2's 14:56:34 <haleyb> i have left comments regarding this 14:57:16 <lajoskatona> ralonsoh also mentioned that he has technical questions anyway for the commit 14:57:19 <haleyb> ralonsoh: did you have a technical issue with the change? 14:57:37 <haleyb> the open question was should we revert 14:57:40 <ralonsoh> I'll comment today this patch, I need to make a reasonable statement 14:57:58 <ralonsoh> maybe not, but it needs to be very clear for anyone in the community\ 14:58:02 <ralonsoh> specially for cores 14:58:14 <ralonsoh> that we cannot auto-merge our patches 14:58:19 <ralonsoh> having said that 14:58:22 <lajoskatona> +1 14:58:34 <ralonsoh> I did that 1 month ago, but with a trivial patch that was affecting the CI 14:58:41 <ralonsoh> and I commented that in the patch 14:58:52 <ihrachys> oh that's author merging their own patch without any +2 from anyone else? wow :) 14:59:07 <ihrachys> (thought at first it's just +2 instead of two; nah that's zero) 14:59:15 <ralonsoh> so we need to be honest having +2 powers 15:00:38 <opendevreview> Merged openstack/os-vif unmaintained/victoria: Update .gitreview for unmaintained/victoria https://review.opendev.org/c/openstack/os-vif/+/911271 15:00:38 <haleyb> right. i can understand there being something lost in translation, culturally, where words imply things like being Ok with the patch 15:01:27 <haleyb> but please always wait for +2's from others 15:02:02 <haleyb> i can understand Liu is frustrated as it seems he is the only one doing ML2/OVS work 15:02:22 <ralonsoh> I disagree with this statement 15:02:30 <ralonsoh> we all do OVS support, he does features 15:02:40 <lajoskatona> +1, others also work on it and use and give feedback with bugs and patches 15:02:46 <ralonsoh> if he wants OVS to be alive, we could have assigned the eventlet depreaction 15:02:47 <ralonsoh> for example 15:02:50 <slaweq> TBH I don't really got his frustration - I didn't saw him on IRC asking for reviews of those patches, he is not active on the meetings, etc. 15:03:01 <haleyb> ralonsoh: sorry, bad wording on my part 15:03:40 <slaweq> and doing things like that is IMO violating our rules, nobody else of us is doing similar things really 15:03:53 <haleyb> slaweq: understood, and i asked that he do that going forward, there is some overlap with EU at least to ping people 15:05:54 <ihrachys> let's just keep an eye that it's not happening going forward. everyone makes mistakes sometimes. :) if there's technical argument beyond rules, this can be brought up of course too. 15:06:40 <lajoskatona> +1, I think from all timezones there will be somebody who overlaps so can be asked on IRC or on mail list 15:06:40 <haleyb> so i'm in a bind here as PTL obviously, not sure how far to push. if it happens again though i think we will need to re-visit things 15:07:05 <ralonsoh> ^ agree 15:07:17 <lajoskatona> haleyb: ack 15:07:21 <slaweq> haleyb +1 to what You said 15:07:31 <svinota> @lajoskatona, looks like I missed the meeting for one hour :) TZ issues. I'll try next week then 15:07:33 <haleyb> i know lajoskatona and myself have been reviewing one of his series, but they are complicated things 15:07:46 <ralonsoh> svinota, good to read you! 15:07:52 <ralonsoh> join us next week, of course 15:07:58 <lajoskatona> svinota: Hi :-) 15:07:59 <svinota> ralonsoh, =^_^= 15:08:13 <lajoskatona> Just one more thing for on-demand (overtime...): bpetermann has a patch long waiting in n-lib: https://review.opendev.org/c/openstack/neutron-lib/+/903971 15:08:15 <svinota> hallå dudes, long time no see 15:08:15 <haleyb> ok, we are over time, thanks for the comments on ^^^ 15:08:21 <lajoskatona> if you have time please check it 15:08:56 <ralonsoh> lajoskatona, I still keep my comment in this patch 15:09:37 <bpetermann> I'm not sure what I should change though 15:09:41 <haleyb> ok, have a good week everyone, and ping people here for reviews and/or add them to the priorities board 15:09:45 <lajoskatona> ralonsoh: ack, thanks, 15:09:47 <haleyb> #endmeeting