14:00:27 <haleyb> #startmeeting networking
14:00:27 <opendevmeet> Meeting started Tue Jun 11 14:00:27 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:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <opendevmeet> The meeting name has been set to 'networking'
14:00:33 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh
14:00:34 <mlavalle> \o
14:00:49 <slaweq> o/
14:00:52 <ralonsoh> hello
14:00:55 <ihrachys> o/
14:00:59 <ykarel> o/
14:01:17 <lajoskatona> o/
14:01:23 <obondarev> o/
14:02:10 <haleyb> looks like we have quorum
14:02:13 <haleyb> #topic announcements
14:02:24 <haleyb> We are now in Dalmatian release week (R - 16)
14:02:32 <haleyb> #link https://releases.openstack.org/dalmatian/schedule.html
14:02:53 <frickler> o/
14:02:55 <rubasov> o/
14:03:57 <haleyb> we did do a neutron-lib release last week for some things, so it is being used in the gate, the 'bump' patch hasn't merged yet though
14:04:17 <haleyb> Reminder if you have a topic for the drivers meeting on Fridays, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
14:05:56 <haleyb> and just a reminder that if you have a feature planned and haven't started work on it, please start working on it
14:06:22 <haleyb> i will go through the ptg notes this week as i had some items in there for this cycle
14:06:42 * slaweq needs to do the same
14:06:44 <haleyb> that was all i had
14:07:05 <haleyb> oh, and i see ralonsoh is back - welcome back! hope you had a good leave
14:07:13 <ralonsoh> thank you!
14:07:18 <mlavalle> +1
14:07:32 <lajoskatona> +1
14:08:11 <haleyb> we can move onto bugs
14:08:13 <haleyb> #topic bugs
14:08:23 <haleyb> jlibosva was the deputy last week
14:08:32 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/W2TC6LKDC6FYKJK2MD22PUP3PGAT2HWM/
14:09:11 <haleyb> there was one un-assigned bug
14:09:15 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2067851
14:09:23 <haleyb> Packets dropped in br-int bridge
14:10:20 <haleyb> large E-W burst shows packet drops, but drop counters don't show it
14:10:49 <haleyb> i think if we just added some notes on where else to look it would be helpful
14:10:57 <ralonsoh> (recommendation: not to use hybrid plug --> qvoxxx but native)
14:11:11 <slaweq> IMHO this is more likely to be asked on the ovs mailing list for example
14:11:56 <haleyb> slaweq: right, and hybrid plug as well, hadn't noticed that
14:12:07 <haleyb> i will add a quick note and mention the ovs list
14:12:29 <slaweq> I don't think hybrid plug is issue here as qvo is veth end which is in the br-int
14:12:47 <slaweq> so it probably wouldn't change if they would try non hybrid plug
14:13:06 <ralonsoh> but the linux bridge could be the one dropping the packages
14:13:18 <slaweq> oh, maybe
14:13:20 <slaweq> yeah
14:13:31 <slaweq> so that is one thing we can recommend them to check
14:13:41 <slaweq> if not then go to the ovs community IMO
14:13:51 <haleyb> it also didn't mention which ovs version, a 3.x release would be desired
14:15:47 <haleyb> all other bugs have assignees, i did have a question about one though
14:15:58 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2068761
14:16:28 <haleyb> mtomaska: this is a revert, but in the bug you mention 'selectin'
14:18:00 <slaweq> I think that the idea here is to do revert first and backport this revert to stable branches too
14:18:12 <slaweq> and later change it to use 'selectin' in master branch
14:18:13 <ralonsoh> ^^ agree (and the test this new option)
14:18:28 <haleyb> i don't know the back story of the original patch myself, but since i have a 'selectin' change up for review didn't want to miss this in my change
14:19:26 <slaweq> original patch was proposed long time ago when dansmith raised to us issues that neutron is making A LOT of the sql queries during e.g. tempest job run
14:19:27 <ralonsoh> but we can revert (including stable branches) and then apply your patch
14:19:31 <haleyb> i have a selectin discussion in on-demand
14:19:51 <slaweq> with ralonsoh we were trying to optimize it and the only thing we found was that query for tags
14:20:06 <ihrachys> selectin is unrelated to revert; but yes, will have to pick up the change to not miss this instance of subquery
14:20:18 <ralonsoh> the only goal was that, to reduce the queries in the logs
14:20:20 <slaweq> but now it seems it caused performance regression in case when there is a lot of tags associated with port
14:20:30 <haleyb> slaweq: ack, just wanted to make sure ihrachys was happy as well since there was a -1 there
14:20:41 <ihrachys> I am not happy with the commit message
14:21:13 <ihrachys> 1. it's malformed - there's a single line that spands hundreds of characters.
14:21:22 <ihrachys> (which is minor but must be fixed)
14:22:16 <ihrachys> 2. it doesn't document what everyone claims about the number of logs being irrelevant to actual performance. which may be true - I don't question it - but then if that's the rationale, document it. it shouldn't be hard to make this claim in writing in commit message.
14:23:11 <ihrachys> once these are handled, I will not -1 it. I will happily rely on others' knowledge about the number of logs not being a real issue.
14:23:30 <haleyb> ihrachys: ok, let's get the message fixed and better document the issue, not sure if mtomaska is around today
14:23:42 <ralonsoh> it's around and checking now
14:23:48 <ihrachys> he is, seen him in slack
14:24:11 <slaweq> just to be clear - it wasn't about number of logs
14:24:41 <ihrachys> "The initial reason for this change was to reduce amount of SELECT logs"
14:24:48 <slaweq> dansmith may have more details but IIRC he was trying to optimize i/o load made by ci jobs on the ci infra
14:24:56 <ihrachys> quoting. so let's make the commit message correct, whatever the correct is
14:25:10 <ykarel> +1
14:25:24 <slaweq> and he came to the conclusion that neutron is far ahead of every other project with making sql queries
14:25:31 <slaweq> so we have tried to optimize that somehow
14:25:37 <dansmith> whatever patch wasn't from me was it? I was raising the flag about the query load yeah
14:26:09 <dansmith> but yeah, neutron was doing like an order of magnitude more select calls for a given run than other services
14:26:12 <slaweq> ihrachys I know that this is what current commit message says and I already explained to mtomaska that this is not correct
14:26:36 <ihrachys> ok. then we shouldn't +2 patches with incorrect commit messages! :)
14:26:37 <slaweq> dansmith patch was from me :)
14:26:46 <dansmith> ack :)
14:27:25 <slaweq> ihrachys you're right, my bad. I just removed my vote
14:28:08 <ihrachys> thanks. I think the next steps are clear - fix / clarify commit message. maybe if we still are not sure the revert is totally innocent, report a LP to follow up on it.
14:28:48 <haleyb> +1
14:29:22 <haleyb> are there any other bugs to discuss?
14:30:02 <haleyb> This week obondarev is the bug deputy, next week will be isabek
14:30:08 <haleyb> obondarev: is that good for you?
14:31:08 <opendevreview> Jay Jahns proposed openstack/ovn-bgp-agent master: Announce lrp ip if advertisement method is subnet  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/921516
14:31:49 <haleyb> and since i have not seen isabek in a while, does anyone here work with him to ping him?
14:32:41 <haleyb> ok, i'll try and follow-up offline
14:33:12 <haleyb> #topic specs
14:33:27 <haleyb> #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open
14:33:46 <obondarev> haleyb: yes sure
14:33:49 <haleyb> slaweq: i think we can merge the pre-commit one, will look after meeting
14:33:57 <haleyb> obondarev: thanks!
14:34:16 <slaweq> thx
14:34:48 <haleyb> there is some discussion in the other
14:34:51 <haleyb> #link https://review.opendev.org/c/openstack/neutron-specs/+/920681
14:34:59 <haleyb> i have not reviewed yet
14:36:54 <haleyb> #topic community-goals
14:37:19 <haleyb> lajoskatona: i see the horizon change is green, hopefully you get some core reviews
14:37:35 <lajoskatona> I have to ping the horizon folks again to have attention
14:39:34 <haleyb> slaweq: i don't seem to have your current community goal in the wiki, will need to add it
14:39:48 <slaweq> thx
14:40:04 <slaweq> I still need to finish some internal tasks and then get back to the SRBAC stuff
14:40:10 <haleyb> still has service role, which is complete
14:40:18 <haleyb> ack
14:40:37 <lajoskatona> is there a consensus for the drop eventlet topic?
14:40:53 <slaweq> yes, but we need now to use service token while communicating with e.g. nova
14:41:10 <ihrachys> lajoskatona consensus where? does neutron have any specific plans?
14:41:15 <slaweq> and test that (I need to sync with @gmann on that part at some point)
14:41:29 <lajoskatona> I mean the community as a whole (for this one: https://review.opendev.org/c/openstack/governance/+/902585 )
14:42:16 <haleyb> the timeline i had (from the ptg) was
14:42:22 <haleyb> 2025.2 for co-existence
14:42:29 <haleyb> 2027.2 for migration
14:43:21 <haleyb> personally, i think it's a good plan in the governance doc
14:44:02 <haleyb> but neutron does not have an owner for any work at the moment
14:44:03 <lajoskatona> haleyb: ack, we go for asyncio? yes the last update is more concrete perhaps
14:44:19 <ralonsoh> did we check the tasks to fix that in neutron?
14:44:34 <opendevreview> Merged openstack/neutron-specs master: Add pre-commit configuration  https://review.opendev.org/c/openstack/neutron-specs/+/918306
14:44:37 <ralonsoh> for example, remove evenlet from agents, fix OVN with wsgi, etc
14:45:02 <opendevreview> Jay Jahns proposed openstack/neutron-tempest-plugin master: Add check to pick up network's dns_domain if present  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921772
14:45:05 <ralonsoh> haleyb, right, that needs an owner, first of all
14:45:49 <haleyb> ralonsoh: the OVN with wsgi is still an issue
14:46:07 <ralonsoh> the bug is still open
14:47:00 <ralonsoh> I'll ping Lucas to check the status
14:47:11 <haleyb> yes, and last i asked about it the work was non-trivial
14:49:28 <ihrachys> so who's the owner? :)
14:49:57 <ralonsoh> I can take it and do my best
14:50:05 <ralonsoh> but for sure I'll need your help
14:50:30 <ihrachys> thank you. I think we will need to read on it, I for one am not well versed in asyncio.
14:50:47 <haleyb> ralonsoh: thanks, and I will help where i can
14:51:44 <haleyb> let's move on
14:51:48 <haleyb> #topic on-demand
14:52:02 <haleyb> i had added two topics, but want to see if others have any
14:52:25 <mlavalle> none from me
14:52:45 <haleyb> alright, my first was regarding 'selectin' load strategy
14:52:49 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/920933
14:53:14 <haleyb> once neutron-lib was released that started to pass
14:53:27 <haleyb> but it will need a rebase on the revert we mentioned earlier
14:53:54 <haleyb> and i now wonder if we should add a hacking check to not allow lazy='subquery' any longer
14:53:59 <ihrachys> yes pls
14:54:23 <ykarel> haleyb, nice, btw so you observed that it also helped in memory usage with cover jobs?
14:54:23 <lajoskatona> good idea
14:54:42 <haleyb> the reason to merge that sooner than later was to get some cycles testing with it
14:55:07 <haleyb> ykarel: no, didn't seem to help memory consumption, but will try again with new neutron-lib
14:55:58 <ykarel> ohkk, CI should already have newer neutron-lib
14:56:48 <haleyb> ykarel: right, and i'll run some tests locally when a fresh VM, but 'coverage' tool itself seems to be the memory hog here
14:57:02 <ykarel> ack
14:57:27 <haleyb> ykarel: i will have to look at your changes regarding this, i did not forget
14:57:37 <haleyb> i.e. swap, etc
14:57:44 <ykarel> +1
14:58:20 <haleyb> my other topic was regarding a ptg goal - migrate from wsgi scripts to python module paths
14:58:53 <haleyb> there were two reviews posted right after ptg from stephenfin (thanks!) - i have since rebased and will do again if necessary, but need some reviews
14:59:01 <haleyb> https://review.opendev.org/c/openstack/neutron/+/916406
14:59:07 <haleyb> https://review.opendev.org/c/openstack/neutron/+/916407
14:59:47 <haleyb> so if anyone has some cycles, thanks in advance
15:00:12 <haleyb> and we are out of time
15:00:25 <lajoskatona> do we have/do we need  devstack support for this?
15:00:26 <haleyb> ci meeting starts now, video today
15:01:04 <haleyb> lajoskatona: i think there was a patch for that, don't know if we need more for neutron, good question
15:01:10 <frickler> lajoskatona: there should be related devstack patches, yes
15:01:22 <haleyb> https://review.opendev.org/q/topic:%22remove-wsgi_scripts%22
15:01:24 <lajoskatona> haleyb, frickler: thanks
15:01:41 <haleyb> thanks for coming everyone
15:01:46 <haleyb> #endmeeting