14:00:17 <haleyb> #startmeeting networking
14:00:17 <opendevmeet> Meeting started Tue Jul 30 14:00:17 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:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:17 <opendevmeet> The meeting name has been set to 'networking'
14:00:19 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh
14:00:20 <mlavalle> \o
14:00:27 <elvira> o/
14:00:28 <ykarel> o/
14:00:49 <ralonsoh> hi
14:00:55 <bcafarel> o/
14:01:02 <slaweq> o/
14:01:23 <haleyb> hi everyone
14:01:26 <haleyb> #topic announcements
14:01:43 <haleyb> We are now in Dalmatian release week (R - 9)
14:01:48 <rubasov> o/
14:01:53 <haleyb> Non-client library freeze: August 22nd, 2024 (R-6 week)
14:01:59 <haleyb> Client library freeze: August 29th, 2024 (R-5 week)
14:02:06 <haleyb> Dalmatian-3 milestone: August 29th, 2024 (R-5 week)
14:02:42 <haleyb> so we are pretty close to the end of D
14:03:31 <haleyb> hopefully we have a happy gate so we can merge code :-)
14:03:52 <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:04:23 <haleyb> anything crazy happen last week?
14:04:55 <ralonsoh> I think most of the CI problems are addressed
14:04:56 <mlavalle> we didn't wreck the place \o/
14:05:28 <haleyb> good to know :)
14:05:54 <haleyb> i am still digging out from a backlog, so feel free to ping me on irc for anything important
14:05:56 <obondarev> o/
14:06:14 <haleyb> #topic bugs
14:06:27 <haleyb> bcafarel was the deputy last week, here is a link to his report
14:06:33 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NZKXVL2DHNFLKEEXETJ2JZYMQM5DALCZ/
14:07:10 <haleyb> there are a few without assignee
14:07:14 <bcafarel> on the 3 unassigned bugs, I see you checked the low-haning fruit one, also thanks ralonsoh for checking first one
14:07:20 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2074207
14:07:28 <haleyb> DHCP agent makes endless attempts to configure a network with MTU < 1280
14:07:46 <haleyb> i thought this was related to a previous bug, but it's slightly different
14:08:03 <haleyb> ralonsoh: just noticing you added a comment
14:08:14 <ralonsoh> I think it makes sense not to add the ipv6 metadata address if there are no ipv6 subnets
14:08:31 <ralonsoh> in any case, if you have ipv6 enabled in your env, you should not used smaller mtus
14:08:39 <ralonsoh> but don't fail because of us
14:09:04 <haleyb> ralonsoh: ack, i couldn't tell whether you thought it was invalid, but i agree we could fix this with a check
14:09:29 <haleyb> i can take it if noone else wants it as i worked on the last one
14:10:20 <haleyb> i don't know why people use small mtus like that, but...
14:11:01 <haleyb> next bug is
14:11:04 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2073872
14:11:13 <haleyb> Neutron L3 agent not create ECMP in HA router but in single mode is ok
14:12:15 <haleyb> looks like l3-ha differs from "regular" l3 in adding/deleting routes
14:13:26 <slaweq> I can try to maybe reproduce it and look quickly if I will have some time, but not promissing anything for now
14:13:35 <haleyb> this is reminding me of a previous bug where we had issues with overlapping routes, in this case it's just the gateway
14:14:09 <haleyb> slaweq: thanks, i'll watch it
14:14:31 <haleyb> last unassigned is
14:14:35 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2074056
14:14:43 <haleyb> Invalid documented security group rule protocol "any"
14:14:59 <haleyb> I added a comment here based on what i knew
14:15:16 <haleyb> the "any" keyword is only actually valid when using OSC, not the API
14:15:34 <haleyb> but the API ref says "any" is valid
14:16:39 <slaweq> IMO if Openstackclient accepts 'any' as valid value, we may accept it on the server side as well to be more consistent with the cli tool
14:16:47 <slaweq> it should be easy to do
14:16:51 <haleyb> We can clean-up the doc to say "use None or 0", but i was wondering if anyone thought supporting "any" as an alias in the API was a good idea
14:17:04 <haleyb> you type faster than me
14:17:13 <slaweq> :)
14:17:21 <ralonsoh> actually the value in the server is "ip"
14:17:33 <ralonsoh> for protocol 0
14:18:05 <haleyb> ralonsoh: yes, i pointed that out in the bug, so there's almost too many choices
14:18:19 <ralonsoh> right, I'm now reading your comment
14:18:33 <ralonsoh> we should not change the CLI (or deprecate "any" with time)
14:19:01 <ralonsoh> or accept both "any" or "ip" (and the deprecate "any")
14:19:24 <haleyb> right, i think i've used 'any' in scripts myself
14:20:23 <haleyb> i think it should be easy enough to support 'any' as an alias on the server side
14:20:42 <slaweq> +1
14:21:08 <ykarel> +1
14:21:11 <haleyb> the only thing that might be an issue is what does the POST return for protocol?
14:21:32 <slaweq> what it returns now for None and 0 values?
14:22:12 <slaweq> I guess it should be the same and we can clearly document that 'any' is just alias for the value which is returned from API
14:22:13 <haleyb> yes, i just didn't know if someone would be confused if it didn't reutrn "any"
14:22:33 <haleyb> slaweq: yes, that sounds good
14:23:17 <haleyb> i will add that info to the bug, and should be able to work on it eventually
14:24:58 <haleyb> i had filed a bug over the weekend, one of those "this is an annoying traceback" seen in the server logs
14:25:05 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2074312
14:25:21 <haleyb> of course my quick fix proposal didn't work
14:25:38 <haleyb> has anyone else noticed those tracebacks?
14:25:51 <haleyb> title was " DB semantic violation seen in neutron-tempest-plugin-openvswitch logs deleting router "
14:26:06 <haleyb> This handler is supposed to handle AFTER events, as in 'AFTER it's committed', not BEFORE. Offending resource event: port, after_delete
14:26:12 <ralonsoh> yes when implementing the new db facade
14:26:25 <ralonsoh> I think this is because we are creating a port inside a transaction
14:26:35 <ralonsoh> sorry, deleting the port
14:26:36 <haleyb> i found the code that should have disabled the warning but it's not working in this case
14:26:56 <ralonsoh> is that somethign recurrent?
14:26:59 <haleyb> there is also one in create_security_group() that doesn't have the "disable the warning" code
14:27:23 <haleyb> every neutron-tempest-openvswitch run has occurrences
14:27:37 <haleyb> neutron-tempest-plugin-openvswitch
14:27:44 <haleyb> i didn't check other logs
14:28:29 <haleyb> one question i had was is it possible to move the code? i figured it would have been done by now if simple
14:28:43 <haleyb> i.e. save the ports and do in a second transaction
14:30:24 <haleyb> ralonsoh: feel free to add a comment to the bug if you have a suggestion, it's not critical just an annoying traceback
14:30:34 <ralonsoh> we can try that, we are deleting the GW port before that txn
14:31:08 <ralonsoh> I'll push a patch but we need to be cautious leaving leftovers
14:31:52 <haleyb> there are at least two TODOs for that same issue, luckily finding GUARD_TRANSACTION is easy
14:32:10 <haleyb> ok, i had no other bugs
14:32:16 <haleyb> any others to discuss?
14:32:44 <haleyb> This week elvira is the bug deputy, next week will be slaweq
14:32:49 <haleyb> is that ok for both?
14:32:55 <elvira> sure!
14:33:51 <haleyb> Current bug count this week: 721, up 14 from last run
14:34:22 <haleyb> #topic community-goals
14:34:36 <slaweq> good for me
14:35:03 <haleyb> We merged the MANAGER role and added documentation, so good there, thanks slaweq !
14:35:21 <slaweq> yeah, this can be IMO consider as done finally
14:36:23 <haleyb> lajos continues to work on neutronclient deprecation
14:36:28 <haleyb> #link https://review.opendev.org/q/topic:%22bug/1999774%22
14:37:08 <haleyb> fixes all for horizon
14:38:30 <haleyb> ralonsoh: and it looks like you just have one change left for evenlet deprecation?
14:38:39 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/924317
14:38:46 <ralonsoh> I'm currently working in an issue related to wsgi and OVN
14:38:49 <haleyb> #link https://review.opendev.org/q/topic:%22bug/2069581%22
14:38:53 <ralonsoh> that is part of the eventlet server deprecation
14:39:20 <ralonsoh> yeah, ml2/ovn won't work right now with wsgi (it was 1 week before)
14:39:29 <haleyb> :(
14:39:39 <ralonsoh> so just investigating https://bugs.launchpad.net/neutron/+bug/2075147
14:39:49 <ralonsoh> and that's all
14:39:53 <haleyb> and i do see the governance change merged
14:39:55 <haleyb> ack, thanks
14:40:02 <haleyb> #link https://review.opendev.org/c/openstack/governance/+/902585 (merged)
14:40:54 <haleyb> #topic on-demand
14:41:14 <haleyb> we already talked about the dhcp-agent looping bug
14:41:19 <haleyb> any other topics?
14:41:38 <ralonsoh> not from me
14:42:16 <haleyb> ykarel: CI meeting in-person today?
14:42:32 <ykarel> haleyb, sent a cancellation mail for today
14:42:44 <haleyb> ykarel: ack
14:43:02 <haleyb> ok, if nothing else we are done, have a good week everyone!
14:43:09 <haleyb> #endmeeting