14:01:59 <haleyb> #startmeeting networking
14:01:59 <opendevmeet> Meeting started Tue Jun 18 14:01:59 2024 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:59 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:59 <opendevmeet> The meeting name has been set to 'networking'
14:02:07 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh
14:02:08 <mlavalle> \o
14:02:12 <ihrachys_> o/
14:02:16 <ralonsoh> hello
14:02:32 <slaweq> o/
14:02:46 <rubasov> o/
14:02:56 <ykarel> o/
14:03:25 <haleyb> #topic announcements
14:03:58 <haleyb> We are now in Dalmatian release week (R - 14)
14:04:09 <haleyb> #link https://releases.openstack.org/dalmatian/schedule.html
14:04:18 <haleyb> The Dalmatian-2 milestone will happen next month, on July 4th, 2024
14:04:43 <haleyb> At milestone-2, the release team will propose releases for any library that has not been otherwise released since milestone-1
14:05:48 <haleyb> So anything we want to get out there in beta form should try and land by then
14:07:01 <haleyb> One of those things that we did land last week was changing the DB load strategy to 'selectin', so if you notice any differences or DB issues please raise them
14:07:15 <mlavalle> ack
14:07:40 <frickler> should this improve performance?
14:08:19 <ralonsoh> yes with the nested resources
14:08:32 <ralonsoh> for example tags of a port
14:09:22 <frickler> ok, so would need dedicated test cases? did anyone actually perform some load tests?
14:10:15 <frickler> but also we can discuss this later in open discussion
14:10:17 <ralonsoh> that would be desirable, for sure
14:11:00 <haleyb> frickler: i did not, it was more driven by our ML discussion with Mike
14:12:12 <haleyb> i have been out for a few days, was there anything important that happened that i should be aware of?
14:12:38 <frickler> there was the wsgi issue gtema pushed earlier today
14:12:54 <frickler> #link https://review.opendev.org/c/openstack/neutron/+/922185
14:13:32 <frickler> breaking vpnaas and n-d-r iiuc
14:13:57 <haleyb> frickler: ack, let's talk about that in bugs in a second
14:14:32 <haleyb> my only other announcement is tomorrow is a US holiday for some (Juneteenth), I am out not sure about others
14:15:41 <mlavalle> we will be out as well in the USA
14:15:41 <haleyb> #topic bugs
14:15:47 <haleyb> mlavalle: ack
14:16:11 <haleyb> obondarev was the bug deputy last week
14:16:19 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QKSMGG3AKXKMVCIJWNSBUKNHAT3SOLFG/
14:16:59 <haleyb> we can talk about the wsgi issue first
14:17:32 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069689
14:18:08 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/922185
14:18:38 <ihrachys_> still pep8ing even though noqa is added?
14:19:00 <gtema> yes, and that drives me crazy - locally it passed
14:19:01 <haleyb> i think you have to give the W number after
14:19:05 <haleyb> ?
14:19:34 <ihrachys_> that's pylint, maybe have a different ignore comment?
14:19:35 <gtema> can try, but here there are 2 Ws
14:21:07 <haleyb> i'm sure we can figure it out, maybe it's just different versions of things?
14:21:28 <haleyb> is the end goal to fix those extensions?
14:21:42 <ralonsoh> there are patches to fix them
14:21:52 <gtema> yes, there are 2 patches for the extensions
14:21:59 <ralonsoh> https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/922190
14:22:02 <gtema> one surprisingly passing (while locally pep failed logically)
14:22:03 <ralonsoh> https://review.opendev.org/c/openstack/neutron-vpnaas/+/922189
14:22:07 <gtema> another fail
14:23:02 <haleyb> gtema: so we can un-do this workaround once those merge?
14:23:34 <gtema> yes. Problem is that you can actually merge extensions fixes after you release neutron
14:23:51 <gtema> then merge/release extensions and then undo neutron change
14:25:05 <haleyb> ok, so we have to do a release for ndr and vpnaas first, got it
14:25:34 <haleyb> sorry about the breakage, luckily it was a simple fix
14:25:55 <gtema> np
14:26:56 <haleyb> next bug
14:27:08 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069482
14:27:16 <haleyb> ipv6-only metadata doesn't work with OVN
14:27:47 <haleyb> mlavalle: i wonder if i broke this with recent metadata work
14:28:24 <mlavalle> haleyb: I will take a look. Thanks. I'll fix it anyway
14:29:19 <mlavalle> but I doubt your recent work is the culprit. I think the problem came since Daniel's original patch
14:30:08 <haleyb> mlavalle: there was another change in progress to retry getting the metadata port, it shouldn't actually be required but will find it in case it helps at all
14:30:30 <mlavalle> ok, thanks
14:30:31 <haleyb> thanks for looking into this
14:31:42 <mlavalle> :-)
14:31:45 <haleyb> next bug
14:31:49 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069061
14:31:57 <haleyb> Investigate 'selectin' relation optimization with newer SQLAlchemy
14:32:30 <haleyb> mtomaska1: is there more to this than the reverts?
14:32:50 <ihrachys_> I think that's a bug to explore what the revert broke (potentially)
14:33:35 <ralonsoh> but we already merge the revert and the selectin patch
14:33:48 <ihrachys_> (that it talks about a particular solutuion - selectin - I think is wrong. selectin may have nothing to do with the effect of the revert.)
14:33:52 <ralonsoh> we can use this patch for what was commented before: to test the performance
14:34:34 <ralonsoh> right, the description doesn't match the title
14:35:05 <haleyb> ralonsoh: ack, especially since tags is one of the areas it should help
14:35:13 <ihrachys_> we can definitely use this LP for perf testing for selectin. but we should then have another LP to check if revert didn't break something else - which was the original explanation given in the revert commit message as to why this LP exists.
14:35:23 <ralonsoh> it is easy to create a resource (port) and multiple tags to test that
14:36:03 <ihrachys_> ok well maybe not the "in commit message" but in "discussions around the patch" is more correct. I see the commit message still says it's about selectin.
14:36:53 <ralonsoh> sorry, I don't understand your comment here
14:37:04 <ralonsoh> the original code was working and was tested
14:37:39 <ihrachys_> I mean that the revert was merged with no thought given as to whether it broke anything (while fixing an issue with tags slowliness). I *hoped* that we will follow up with checking it.
14:37:40 <ralonsoh> the patch changing the load method to "joined" didn't change the results (and the tests are still valid)
14:38:08 <ralonsoh> right, that was manually tested but there are not tests to validate that
14:38:11 <ihrachys_> (I assume there was a good reason for the original patch to merge here; could be wrong)
14:38:34 <ralonsoh> we can try that in rally, maybe
14:38:52 <ihrachys_> regardless, something to explore I think - check the "number of sql select queries; try to understand if they regressed and whether it's an indicator of a problem..."
14:39:29 <ralonsoh> no, that was just cosmetic (the number of queries)
14:39:49 <ralonsoh> not to be always pointed by the U/S QA team, blaming us for the poor performance
14:40:05 <ihrachys_> welp that sounds really bad
14:40:21 <ralonsoh> selectin will fix both: number of queries and performance
14:40:42 <ihrachys_> ok
14:41:52 <haleyb> so that bug just needs an owner, not sure if mtomaska1 will be able to look but can follow-up with him
14:43:17 <haleyb> next bug
14:43:21 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069201
14:43:29 <haleyb> ovn octavia provider related
14:44:27 <haleyb> i'll have to ping fernando, don't see him here
14:44:46 <ralonsoh> today is offline
14:45:10 <haleyb> ralonsoh: ack, thanks
14:45:15 <haleyb> have a few more bugs
14:45:21 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069543
14:45:28 <haleyb> instance tap port has dead vlan when parent port for trunk
14:45:53 <haleyb> i see rubasov just picked this up, thanks!
14:45:57 <rubasov> I'll take a look
14:46:56 <haleyb> next
14:47:01 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069071
14:47:09 <haleyb> address pair not working with oslo policy http check
14:47:32 <haleyb> oleg thought might be a formatting issue in their policy file, waiting for response
14:48:13 <ralonsoh> hmmm I've seen that before, I can confirm that testing it
14:48:23 <ralonsoh> this is because we are not defining something in the API
14:48:33 <ralonsoh> this is why is trying to convert neutron_lib.constants.Sentinel
14:48:45 <ralonsoh> I think that could be legit
14:49:05 <ralonsoh> I'll take it
14:49:30 <haleyb> ralonsoh: thanks
14:50:57 <haleyb> there are two more bug, might as well go through quickly
14:51:06 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069409
14:51:16 <haleyb> Addding route in qrouter namesapce failing as Nexthop has invalid gateway
14:52:05 <haleyb> the submittor took ownership, i'll follow to see if there are other responses
14:52:49 <haleyb> last one
14:52:53 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2069149
14:53:07 <haleyb> Designate DNS and SSLError 524297
14:54:04 <haleyb> so deleting FIP that has DNS entry gives an error
14:55:28 <haleyb> as far as i knew this was working correctly, will have to wait for more info
14:56:27 <johnsom> It seems like we should have test coverage for this scenario
14:57:19 <haleyb> johnsom: seems like it. this is a pretty basic scenario that should be working
14:57:22 <ihrachys_> what's special about the scenario? don't we deploy designate apis via tls in designate gate?
14:58:52 <johnsom> On the Designate side, we co-gate with neutron-tempest-plugin-designate-scenario, but I don't think that runs with TLS
14:59:18 <johnsom> I don't know if there is a neutron job running with TLS
14:59:54 <ralonsoh> tempest-multinode-full-py3
15:01:28 <johnsom> Ah, cool. So now the question is does the test suite cover the "insecure" option as mentioned on the bug. Though, I'm not sure the error relates to a validation issue.
15:02:26 <haleyb> johnsom: not sure about insecure testing
15:02:51 <ralonsoh> sorry, folks, I need to drop in 1 minute
15:02:53 <haleyb> we are actually over time and neutron-ci meeting needs to start
15:03:07 <slaweq> I have to drop too
15:03:09 <slaweq> see You
15:03:18 <haleyb> we can try and work that issue in the bug to narrow it down
15:03:27 <haleyb> thanks for coming everyone and have a good week
15:03:32 <haleyb> #endmeeting