14:00:25 <haleyb> #startmeeting networking 14:00:25 <opendevmeet> Meeting started Tue Nov 12 14:00:25 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:25 <opendevmeet> The meeting name has been set to 'networking' 14:00:27 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:28 <mlavalle> \o 14:00:30 <elvira> o/ hi 14:00:36 <obondarev> o/ 14:00:36 <ralonsoh> hello 14:00:45 <ykarel> o/ 14:01:26 <lajoskatona1> o/ 14:01:29 <ihrachys> o/ 14:01:40 <s3rj1k> hi 14:01:42 <haleyb> hi everyone, i'll get started 14:01:45 <haleyb> #announcements 14:02:08 <slaweq> o/ 14:02:17 <haleyb> i've been out a couple days hopefully it was quiet 14:02:34 <rubasov> o/ 14:02:51 <haleyb> ralonsoh: i did notice the release patches, thanks for reminding me 14:02:55 <ralonsoh> yw 14:03:27 <haleyb> #link https://releases.openstack.org/epoxy/schedule.html 14:03:39 <haleyb> it's week R-20 for Epoxy 14:03:53 <haleyb> Epoxy-1 milestone: November 14th, 2024 14:04:22 <haleyb> so in a couple of days 14:04:38 <haleyb> 2025.1 Epoxy final release: April 2nd, 2025 14:04:41 <haleyb> so a while to go 14:05:22 <haleyb> 2023.1 is transitioning to unmaintained, one of those release patches is for that, i'll make sure the backlog is clear before approving 14:05:49 <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:06:06 <haleyb> I will send an email by thursday if canceled 14:06:31 <haleyb> Let's continue to use the priorities dashboard for patches in the "ready to merge" state, it has worked well so far - see wiki for link (wiki does not allow url shorteners) 14:06:43 <ralonsoh> there are many RFEs opened last week 14:06:58 <ralonsoh> I don't know if the authors know about the process 14:07:15 <ralonsoh> could be better to inform about this in the LP bugs 14:07:50 <s3rj1k> I've opened 3 RFEs, topic of interest right now is one of them 14:07:55 <haleyb> ralonsoh: ack, i will respond in the bugs, so we will probably have a meeting this friday 14:08:51 <haleyb> i have not triaged any of them, was really off-offline 14:09:29 <haleyb> i did finally send the summary from our epoxy PTG meeting 14:09:35 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ITHWPHWJHRHRXMNMGDESJL4YAU5Y2JFB/ 14:09:40 <ralonsoh> thanks! 14:09:51 <s3rj1k> haleyb: one of them is on agenda of today's meeting, just in case 14:09:53 <haleyb> please comment if i missed or mis-stated anything 14:10:21 <haleyb> s3rj1k: ack, will get to it in on-demand 14:11:08 <haleyb> i did have a couple of things to talk about regarding the PTG notes, both regarding large removal items 14:11:45 <haleyb> first was regarding IPv6 prefix delegation 14:11:56 <haleyb> ihrachys has sent a patch removing it from tree 14:12:36 <ralonsoh> didn't we have an alternative binary? 14:12:36 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/934283 14:13:15 <ihrachys> ralonsoh: elaborate? 14:13:17 <haleyb> ralonsoh: i'm not sure, i know there was the option of OVN doing something, but i had a more basic qquestion 14:13:19 <lajoskatona1> I played with kea 14:13:31 <ralonsoh> right, kea was the proposed alternative 14:13:37 <ralonsoh> another backend replacing dibbler 14:13:38 <lajoskatona1> but kea is not for this usecase and misses a lot of things 14:14:20 <lajoskatona1> but the community is quite responsive and active, so good point for Kea as DHCP backend :-) 14:14:20 <ralonsoh> yes, ovn supports prefix delegation 14:15:05 <haleyb> when i was doing my write-up, i didn't see any conclusion in this section regarding removing all the code, and my memory has already faded, so wanted to make sure that was the consensus 14:15:42 <ralonsoh> so is there no interest right now to implement the OVN part? 14:15:47 <slaweq> I know we had some questions d/s about supporting this feature so do we really want to remove it completely now? 14:17:05 <ihrachys> what does "completely" mean here? it's still in neutron-lib as an option, a driver can implement it. 14:18:29 <haleyb> ihrachys: removing dibbler would be partial, removing IPv6 PD would be completely IMO 14:18:31 <lajoskatona1> you mean "in neutron-lib: that the api extension? 14:18:56 <ralonsoh> there is also the code in the Neutron API 14:19:05 <ihrachys> haleyb: you refer to ipam parts in that patch? 14:19:20 <ralonsoh> yes, for example 14:19:21 <ralonsoh> and db_base_plugin_v2.py 14:19:25 <slaweq> by "completely" I meant removal e.g. related bits from the neutron/db/db_base_plugin_v2.py or ipam 14:19:32 <haleyb> ihrachys: yes, and db and dhcp, etc 14:20:23 <ihrachys> yeah gotcha, I guess I am too trigger happy. I will split this out. 14:20:36 <ralonsoh> +1 14:21:18 <haleyb> right, we shouldn't make it too hard to add a replacement if someone wants to work on it 14:21:31 <lajoskatona1> +1 14:22:12 <frickler> is "experimental" the same as "deprecated and going to be removed"? 14:22:16 <ihrachys> I understand the concern. Not that it's hard to revert afterwards if there's interest, but I see that db / ipam layers can be in theory already used elsewhere (though we don't know about it) 14:22:24 <ihrachys> frickler: effectively yes, the name is unfortunate 14:22:29 <ihrachys> it's a cemetery :p 14:23:13 <ralonsoh> that name was decided because everything under experimental was still tested in the CI but not supported 14:23:20 <slaweq> "cemetery" is much better name to reflect it's purpose 14:23:29 <ralonsoh> and if the CI started to fail, then the decision was to remove it 14:25:37 <rpittau> ralonsoh: changing OVS and OVN branches worked as a charm, thanks! 14:25:46 <ralonsoh> yw 14:28:18 <haleyb> so to loop back - ihrachys will remove traces of dibbler from the tree 14:29:06 <ihrachys> + will update the patch this week to reduce the scope as you suggested 14:30:23 <haleyb> ack, ok my second question about the PTG was regarding Linuxbridge, so similar question 14:30:33 <haleyb> i know this has been in the "cemetary" for a while too 14:31:18 <ralonsoh> We don't have an official migration document, from LB to other backend 14:31:28 <ralonsoh> that could be a stopper for some users 14:31:51 <ralonsoh> in any case, the first thing should be to communicate this decision in the mailing list and wait for feedback 14:31:55 <haleyb> ralonsoh: right, i think that's something maybe we can help with 14:31:57 <ralonsoh> (not too long) 14:32:16 <ralonsoh> haleyb, but that is something not easy, to be honest 14:32:32 <ralonsoh> we can "recommend" this external guide, I don't remember the author 14:32:58 <ralonsoh> that is moving from LB to OVN, if I recall correctly 14:33:11 <haleyb> if we can communicate waht state the driver is in (untested and unmaintained), and the desire to move to OVN, maybe that will get people using it to look at a transition 14:33:21 <haleyb> and bring up unanswered questions, etc 14:33:22 <ralonsoh> https://www.jimmdenton.com/migrating-lxb-to-ovn/ 14:33:28 <ihrachys> we should probably have a guide / reference even if we don't drop the code 14:33:57 <opendevreview> Merged openstack/neutron-lib stable/2024.2: Skip pylint recommendation "too-many-positional-arguments" https://review.opendev.org/c/openstack/neutron-lib/+/934736 14:34:40 <slaweq> I'm not sure but maybe it was noonedeadpunk who made this guide, no? 14:34:52 <ralonsoh> ^^ the link is there 14:34:53 <ralonsoh> https://www.jimmdenton.com/migrating-lxb-to-ovn/ 14:35:28 <haleyb> so i will write something up, with a "strongly recommend migration" due to these reasons 14:36:18 <haleyb> and i do realize there could be unhappy people 14:36:36 <haleyb> so i will work on that, might send it to 1-2 of you for review first 14:37:09 <noonedeadpunk> it was jamesdenton 14:37:21 <slaweq> haleyb there will be unhappy people I guess but from the other hand we were raising this for many years now and nobody really took care of this backend 14:37:52 <noonedeadpunk> slaweq: nobody will as long as it works 14:37:52 <slaweq> thx noonedeadpunk, ralonsoh already found it :) 14:38:10 <noonedeadpunk> and it works "just fine" so far... 14:38:12 <haleyb> slaweq: right, and at least we know CERN is looking at migration 14:38:48 <ihrachys> the code can always be spun off into a separate project; it's not like we ban interfaces for linuxbridge. 14:38:53 <opendevreview> Rodolfo Alonso proposed openstack/neutron stable/2024.2: [stable-only] Group by using the same filtered fields https://review.opendev.org/c/openstack/neutron/+/934733 14:38:56 <noonedeadpunk> well, we are looking for migration from OVS and the path seems to be very tricky so far. If possible. 14:39:02 <lajoskatona1> perhaps this will push NASA also over the treshold to change to something else :üÖ 14:39:04 <noonedeadpunk> I think same is gonna happen with LXB 14:39:24 <noonedeadpunk> mainly due to workloads that have disabled port security but running VRRP inside of VMs 14:39:36 <slaweq> noonedeadpunk if that would be the case, then let's see who will step in to do https://bugs.launchpad.net/neutron/+bug/2087947 - I believe this may be one of those things which really has to be done if this backend would be still there 14:39:50 <haleyb> lift and shift is sometimes the only answer 14:40:51 <haleyb> slaweq: i will even mention such bugs in my email 14:41:24 <noonedeadpunk> I was thinking eventlet removal is actually after 2025.1? At least iirc Nova said it was for them 14:41:34 <noonedeadpunk> to produce another "stable" SLURP 14:41:58 <noonedeadpunk> as I guess driver removal is not appropriate right now anyway? 14:43:01 <ihrachys> noonedeadpunk: the argument is that the deprecated state of linuxbridge was communicated by putting it behind experimental knob, so it's fair game. 14:43:34 <noonedeadpunk> but I'd guess this might be also very tricky to replace? https://github.com/openstack/neutron/blob/fa0f8570106257a88275ba59954a509dbf096d0b/neutron/agent/dhcp/agent.py#L136 14:43:40 <haleyb> we have dug the hole for linuxbridge it's just hard to finsh it off. maybe any email will start a dialogue 14:44:10 <ralonsoh> noonedeadpunk, not at all, we are planning to migrate the user threads to kernel threads 14:44:25 <ralonsoh> we'll find issues, mainly in the API part, but we'll solve it 14:44:35 <haleyb> i think we have a plan for these two items, should move onto bugs with only :15 left 14:44:40 <slaweq> +1 for email - lets send it and see what the reaction will be again 14:44:44 <ihrachys> long story short, haleyb will send email and get the ball rolling and we'll see where chips fall 14:45:11 <haleyb> maybe it's only used with yoga :) 14:45:14 <lajoskatona1> agree, letás send out the email, and wait ÉüÖ 14:45:28 <noonedeadpunk> lxb case in bug report looks like async thing, but yeah... again - not saying to keep lxb. but potentially easier migration would be to ovs if you're gonna keep/sovle it 14:45:39 <haleyb> #topic bugs 14:45:50 <haleyb> elvira was the deputy last week, her report is here 14:45:54 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QIIS7YTCVWYR64BRK7UGASVGU4AGQ3OE/ 14:46:23 <haleyb> there were some unassigned 14:46:36 <haleyb> or at least there were when it was sent 14:47:01 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2087824 14:47:03 <haleyb> random router related test failures since wsgi switch 14:47:08 <haleyb> but i see there is a patch now 14:47:13 <ralonsoh> I'm on this one, yes 14:47:20 <ralonsoh> and a testing patch on top of it 14:47:21 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/934652 14:47:54 <haleyb> ok next is 14:48:00 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2087822 14:48:07 <haleyb> When security group rules have the same normalized CIDR, neutron-ovn-db-sync-util has a wrong log message 14:48:49 <haleyb> mentions incorrect message, but think we patched this 14:49:14 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/890799 14:49:23 <elvira> haleyb: not sure if you mean the patch I linked, but reporter should have that in given their version 14:49:33 <slaweq> I will try to check it as I was doing this "normalized_cidr" thing in the past 14:49:34 <elvira> yes, that is the one 14:50:06 <opendevreview> Dmitriy Rabotyagov proposed openstack/ovn-bgp-agent master: Handle trimming of vlan interface namings https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910654 14:50:07 <haleyb> slaweq: ack, i can take it if you get too busy, we use that script a lot 14:50:30 <slaweq> if you have cycles, feel free to do it 14:51:03 <slaweq> if it will be unassigned next week I can take it then, but if you can earlier, would be great 14:51:28 <haleyb> i should be able to get to it 14:51:32 <haleyb> next is 14:51:38 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2086787 14:51:47 <haleyb> neutron fails with postgres on agents 14:51:51 <ralonsoh> I'm on this one 14:51:59 <ralonsoh> but this is the last postgresql bug I fix 14:52:20 <haleyb> ack, thanks, we should have retired it sooner :) 14:52:32 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/934733 14:53:26 <haleyb> ack, thanks 14:54:22 <haleyb> there were also a few RFEs that i will need to triage, not sure if any saw or commented on them 14:54:49 <haleyb> that was all i had for bugs 14:55:01 <haleyb> slaweq is the deputy this week, i am next week 14:55:19 <noonedeadpunk> ralonsoh: can you please elaborate a bit on what documentation (and maybe where to place it?) you have in mind for https://review.opendev.org/c/openstack/neutron/+/931495 ? 14:55:22 <slaweq> ack, I'm on it already 14:55:26 <haleyb> thanks 14:55:27 <haleyb> moving on 14:55:31 <haleyb> #topic community goals 14:55:38 <ralonsoh> noonedeadpunk, once the meeting is over 14:55:57 <haleyb> ralonsoh: it looks like you started creating bugs for evenlet removal? 14:56:08 <ralonsoh> yes, all the references in 14:56:15 <ralonsoh> #link https://etherpad.opendev.org/p/neutron-eventlet-deprecation 14:56:44 <ralonsoh> but I still need to open the migration to ASGI, that is something that, IMO, should be a consensual decision in the community 14:56:45 <opendevreview> Dmitriy Rabotyagov proposed openstack/ovn-bgp-agent master: Use neutron_lib constants a device name limiter https://review.opendev.org/c/openstack/ovn-bgp-agent/+/934327 14:57:04 <ralonsoh> I'll attend to the oslo meetings and the eventlet-deprecation ones 14:57:09 <ralonsoh> that's all 14:57:11 <slaweq> I marked them all today with "eventlet-deprecation" tag so can be easily found: https://bugs.launchpad.net/neutron/+bugs?field.tag=eventlet-deprecation 14:57:19 <haleyb> ralonsoh: ack, thanks 14:57:22 <ralonsoh> +1 14:57:27 <lajoskatona1> thanks 14:58:27 <haleyb> #topic on-demand 14:58:59 <haleyb> s3rj1k: i noticed you had added something, although it is an RFE 14:59:28 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2086776 14:59:37 <haleyb> it might be something more for friday drivers meeting 14:59:53 <s3rj1k> haleb: yea, I am willing to take this up in case there are no hard objections to proposed RFE 15:00:36 <haleyb> s3rj1k: we would have to discuss and approve in friday's meeting, same time as this one 15:00:56 <s3rj1k> haleb: got it, thanks 15:01:31 <haleyb> ok, will defer that to friday 15:01:36 <haleyb> any other topics, we are over time 15:02:16 <haleyb> ok 15:02:20 <haleyb> #endmeeting