Tuesday, 2024-09-10

opendevreviewBrian Haley proposed openstack/neutron master: DNM: Test tempest port wait patch  https://review.opendev.org/c/openstack/neutron/+/92847200:29
opendevreviewMerged openstack/neutron-tempest-plugin master: refactor: Remove unused code from utils and tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/92846100:51
opendevreviewBrian Haley proposed openstack/neutron master: Add special treatment for 'any' in SG rule API  https://review.opendev.org/c/openstack/neutron/+/92649800:56
opendevreviewLiushy proposed openstack/neutron master: [ovn]Add one periodic task for 'agent_health_check'  https://review.opendev.org/c/openstack/neutron/+/91690303:22
opendevreviewBrian Haley proposed openstack/neutron master: Optionally configure IPv6 metadata address  https://review.opendev.org/c/openstack/neutron/+/92649703:24
opendevreviewBrian Haley proposed openstack/neutron master: Add special treatment for 'any' in SG rule API  https://review.opendev.org/c/openstack/neutron/+/92649803:31
opendevreviewLiushy proposed openstack/neutron master: [ovn]Add one periodic task for 'agent_health_check'  https://review.opendev.org/c/openstack/neutron/+/91690304:56
*** ralonsoh_ is now known as ralonsoh05:48
opendevreviewLajos Katona proposed openstack/neutron master: Functional: Increase Ulimit to 3072  https://review.opendev.org/c/openstack/neutron/+/92875907:40
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Enable iptables debugging in the L3 agent functional tests  https://review.opendev.org/c/openstack/neutron/+/92813608:41
opendevreviewRodolfo Alonso proposed openstack/neutron-tempest-plugin master: Add test for extension "quota-check-limit-default"  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/92877009:10
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Enable iptables debugging in the L3 agent functional tests  https://review.opendev.org/c/openstack/neutron/+/92813609:14
opendevreviewRodolfo Alonso proposed openstack/neutron master: Neutron quota engine checks the resource usage by default  https://review.opendev.org/c/openstack/neutron/+/92672509:19
opendevreviewRodolfo Alonso proposed openstack/neutron-lib master: Add new API extension ``uplink-status-propagation-updatable``  https://review.opendev.org/c/openstack/neutron-lib/+/92782009:31
slaweqykarel ralonsoh lajoskatona hi, if you have a minute, please check https://review.opendev.org/c/openstack/neutron/+/928136, thx in advance10:21
ralonsohsure10:29
ralonsohslaweq, why this: https://review.opendev.org/c/openstack/neutron/+/928136/3/neutron/tests/functional/agent/l3/extensions/test_ndp_proxy_extension.py#4410:31
ralonsohcorrection: not why the change itself but why the tests are failing with this config option?10:38
slaweqralonsoh TBH I don't know but it is failing due to some iptables rules not match in second run, exactly raises https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_manager.py#L47712:02
slaweqand I don't really have time now to investigate this ndp proxy extension so that's why I added TODO there only12:02
opendevreviewMerged openstack/neutron master: Enable iptables debugging in the L3 agent functional tests  https://review.opendev.org/c/openstack/neutron/+/92813612:17
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - TESTING PATCH: neutron-functional-with-uwsgi  https://review.opendev.org/c/openstack/neutron/+/92433513:04
opendevreviewRodolfo Alonso proposed openstack/neutron master: Add source interface in "ping" command in ``ARPSpoofTestCase``  https://review.opendev.org/c/openstack/neutron/+/92879113:04
haleyb#startmeeting networking14:00
opendevmeetMeeting started Tue Sep 10 14:00:31 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'networking'14:00
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh14:00
mlavalle1\o14:00
elvirao/14:00
rubasovo/14:00
ralonsohhello14:00
mtomaskao/14:00
obondarevhi14:00
slaweqo/14:00
ihrachyso/14:01
lajoskatonao/14:01
bcafarelo/14:01
haleybhi everyone, let's get started14:01
haleyb#topic announcements14:01
haleybWe are now in Dalmatian release week (R - 3)14:01
haleybFocus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2024.2 Dalmatian deliverables can be proposed, well ahead of the final 2024.2 Dalmatian release date14:02
haleybAll deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2024.2 branch will be cut 14:02
haleybThis branch will track the 2024.2 Dalmatian release14:02
haleybOnce stable/2024.2 has been created, the master branch will be ready to switch to 2025.1 Epoxy development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2024.2 Dalmatian plans14:02
fricklero/14:02
haleybRelease-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2024.2 branch before a new release candidate can be proposed14:02
haleybOk, so that was a lot of pasting from the wiki14:03
haleybThere is an initial RC1 candidate proposed14:03
haleyb#link https://review.opendev.org/c/openstack/releases/+/92855014:03
haleybI'm assuming master has moved since that was proposed14:03
haleybI will check and update today, but is there anything in the gate that i should be waiting for?14:04
lajoskatonathanks for taking care14:05
haleybAs once that merges, stable/2024.2 will be cut and anything critical will need to be cherry-picked14:05
haleybWe do have until Friday at the latest, so we can look at getting any last minute fixes in14:06
haleybvery quiet, so i'll move on14:07
ralonsohThis patch (I found today): the cycle highlights https://review.opendev.org/c/openstack/releases/+/92828914:07
haleybyes, that was next on my list14:07
ralonsohsorry14:07
haleybnp, it does need a formatting update, but if there's something i missed, or something that doesn't need to be there please comment14:08
haleybi just went through commit messages for ideas14:08
haleyband regarding the RC1 deadline - there are a number of other networking-* projects that also have releases proposed14:09
haleyb#link https://review.opendev.org/q/project:openstack/releases14:10
haleybif you contribute to any of those (too many to list), please check and +114:10
haleybi will go through them later today and verify hashes with master branches14:10
haleybSo just to re-state the deadlines14:11
haleybRC1 deadline: September 13th, 2024 (R-3 week) (this week)14:11
haleybFinal RC deadline: September 26th, 2024 (R-1 week)14:11
haleybFinal 2024.2 Dalmatian release: October 2nd, 202414:11
haleybThanks for everyone's hard work during the cycle, we're almost done :)14:12
haleybthat was all the announcements i had, any others or questions?14:13
haleybok, let's move onto bugs14:14
haleyb#topic bugs14:14
haleybthere were unfortunately a lot of bugs this week14:14
haleybihrachys was the bug deputy, his report is at14:14
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/6UHEMOMG3CM5JN4FHOETKSFGAJOBSYAK/14:14
ihrachyssome of these in the report are not NEW but changed their state though (e.g. more info added or requested)14:15
haleybihrachys: ack14:16
haleybfirst one in the list is14:16
haleyb#link https://bugs.launchpad.net/neutron/+bug/207884614:16
haleybOVN fails to transition router port to ACTIVE, claims L2 provisioning block is still present14:16
ihrachysi reported it; it took several hours of my time and i still could figure it fully out. i dumped all i found in the bug though. if someone is familiar with provisioning blocks / ovn router port transition to active, your help may be fitting.14:17
haleybihrachys: thanks for looking. did you see it more than once?14:19
ihrachysit was once in gate on my patch, hence I had to look and report :)14:19
haleybhttps://review.opendev.org/c/openstack/neutron/+/927631 patch i guess based on the link14:21
haleybwell, if someone has the cycles to look that would be good, but lets get through some of the others14:22
haleybnext is14:22
haleyb#link https://bugs.launchpad.net/neutron/+bug/207904714:23
ralonsohyeah, I saw this job failing all times in the periodic queue14:23
ihrachysoh is it in periodic after all? thought it was experimental.14:24
ralonsohI have no time to review this specific configuration14:24
ralonsohall periodic jobs are also experimental14:24
ralonsoh(not the other way around)14:24
ihrachysif so then I think opensearch exposes the approximate time when it started to fail14:24
ihrachysbecause it was clear on the chart (link in the bug report) when it started to spike14:25
slaweqmaybe we should ping LiuYulong about it as he is main author of this distributed dhcp feature and those jobs14:25
frickleropensearch only goes back 10 days, so if it starts then, that's how much data there are, not necessarily when the issue started14:26
ralonsohand is always the same test14:26
ihrachysfrickler: ah! :(14:26
haleybslaweq: yes, pinging him would be good as it could be related to those changes14:27
ralonsohI though that could be related to the eventlet/wsgi change14:27
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/92795814:27
ralonsohbut this is not the case14:27
ralonsohthought*14:27
haleybI will add Liu and ask about his thoughts14:28
haleybok, next one14:30
haleyb#link https://bugs.launchpad.net/neutron/+bug/207904814:30
haleybMetadata functional tests failing due to connection timeout14:30
ihrachysthink we merged a patch that may help to investigate the next time it hits14:30
haleybyes, there was a patch to enable iptables debug14:31
haleybAssertionError: metadata proxy unreachable on http://[fe80::a9fe:a9fe%port19caee]:80 before timeout14:31
slaweqyes, it was just merged today14:31
slaweqit will log iptables rules applied by the agent, maybe this will help understand why there is no connectivity there14:32
slaweqso far I did not found anything wrong in the logs from the job runs which I was checking14:32
haleybso is it always the rate-limiting test that fails?14:33
slaweqas far as I saw, yes14:33
slaweqand it is always the same test probably14:33
slaweqrelated to ipv6 metadata14:34
haleybright. i'm just thinking of ideas, but wonder if there is something different wrt ipv6 where we hit the limit too soon? or there's just another bug hiding in here14:35
slaweqbut this is failing on the first attempt to reach to the metadata server, so there should be no limit hit yet at all14:36
haleyboh, so either not listening or packets got "lost"14:37
slaweqIMO yes14:37
slaweqthat's why I added this iptables debug to the tests14:38
slaweqas metadata in router namespace should be reachable through the iptables rules14:38
haleybi will watch it and try to look14:38
slaweqthx haleyb 14:38
haleyband we have one more gate failure14:38
haleyb#link https://bugs.launchpad.net/neutron/+bug/207983114:38
ralonsohthat is related to the OVN wsgi migration patch14:39
haleybthis one i took last week, and added tempest as that's where the code lives14:39
ralonsohthanks for taking it14:39
haleybralonsoh: oh, so did you only see the failure with that last wsgi patch?14:39
ralonsohyes14:39
haleybi've been trying to see the "not ACTIVE" string unsuccessfully14:39
haleybok, i might need to add another depends-on to my test patch14:40
ralonsohactually the logs I provided are from this patch, some CI executions14:40
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/92431714:40
ralonsohactually ^^ this patch should be updated with yours14:40
haleybralonsoh: and i will update the tempest patch based on your comments, was thinking about it last night but ran out of time14:40
ralonsohthanks14:41
ihrachyshm. do you have a theory of how does wsgi patch affects the speed of port active transition?14:41
ralonsohI think (I need to confirm that) it replies faster (the API call)14:41
ihrachysah. so it's vice versa - we list ports more quickly?14:42
ralonsohso we receive the event (chassis binding) and we process it at the same time14:42
ralonsohright14:42
ralonsohbut as I said, I need to confirm that14:42
ralonsoh(wsgi is supposed to be faster)14:43
ihrachysack. but the test change seems sane regardless. we should assume a particular slowliness / snappiness of port transitions.14:43
ihrachys*should not14:43
ralonsohthe problem is that after the nova VM creation call, the ports could not be ready yet14:44
ralonsohso I think this check is correct there14:44
ralonsohactually we usually call https://github.com/openstack/tempest/blob/0a0e1070e573674332cb5126064b95f17099307e/tempest/scenario/test_network_basic_ops.py#L12414:45
ralonsohbut not in this case because of project_networks_reachable=False14:45
haleybalright, i'll move on since there's still more unassigned bugs :(14:49
haleyb#link https://bugs.launchpad.net/neutron/+bug/207885614:49
haleybOVN invalid syntax '' in networks14:49
ralonsohwaiting for more info14:50
haleybright, see that now14:50
haleybthere were also some vpnaas ones14:51
haleyb#link https://bugs.launchpad.net/neutron/+bug/208007214:51
haleybFailed to delete vpnaas ipsec-site-connections with 502 error, ORM session: SQL execution without transaction in progress14:51
haleybi will try and ping bodo, don't see him on channel14:53
ihrachysnoticed it in gate once; seems like a clear case of sqlalchemy api not used correctly14:53
lajoskatonaI keep an eye also on it14:53
haleybalright, any other bugs to discuss, running out of time14:55
haleybthis weeks deputy is lucasgomes, next week is jlibosva14:55
haleybi remember someone pinging lucas and he said he's good for this week14:56
haleyband fwiw bug count is staying stable14:56
haleybCurrent bug count this week: 717, up 5 from last week14:56
mlavalle1haleyb: I confirmed with lucas that he will be triaging bugs this week14:56
haleybmlavalle1: thanks14:57
mlavalle1we even had a follow up chat about it at the end of last week14:57
haleybi'll skip over community14:57
haleyb#topic on-demand14:57
haleybanything else to discuss?14:57
haleybso just as a reminder, please only merge bug fixes on master until stable/2024.2 branch created, or ask for an exception request14:59
haleybas i mentioned, i'll be looking at the release patches today/tomorrow14:59
haleybthanks for attending and have a good week fixing bugs :)15:00
haleyb#endmeeting15:00
opendevmeetMeeting ended Tue Sep 10 15:00:40 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2024/networking.2024-09-10-14.00.html15:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2024/networking.2024-09-10-14.00.txt15:00
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2024/networking.2024-09-10-14.00.log.html15:00
ralonsohbye15:01
lajoskatonaBye15:01
mlavalle1\o15:01
slaweqo/15:01
haleyblajoskatona: can you look at https://review.opendev.org/c/openstack/neutron/+/618208 one more time? i know you voted previously, it's an old one but one of the last on the priority dashboard - trying to get some of these closed15:06
haleybihrachys: i see you're watching there too :)15:06
lajoskatonahaleyb: sure,  I will check it15:11
ihrachyshaleyb: the patch is simple (basically a one liner) but I wasn't sure as to the effect of this setting. I wonder why it's not enabled by default in kernel, and what we should be aware of before enabling it.15:20
ihrachyshaleyb: the linked issue in libnetwork gives two options to handle these packets. one is the sysctl knob. another is iptables rule to drop INVALIDs. https://github.com/moby/libnetwork/issues/1090 wonder if the latter would be more isolated. (the former will affect everything on the node, even traffic that does not belong to the agent ports)15:24
ihrachysiptables -I INPUT -m conntrack --ctstate INVALID -j DROP15:24
opendevreviewEduardo Olivares proposed openstack/ovn-bgp-agent master: WIP: add retries to get_device_port_at_ovs  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/92882215:25
ihrachysthere's some concerns about the rule affecting "legit traffic" here though: https://github.com/kubernetes/kubernetes/pull/120412 the PR then switches from the iptables rule to the sysctl knob. so I dunno if one is better or the other.15:30
ihrachysbut that's the root of my sitting on the sidelines here - I don't understand all the implications.15:31
haleybihrachys: it's been a while since i looked at the change, but the sysctl seemed the best option, and it's only in the snat namespace so shouldn't affect other things15:32
ihrachysah correct, I forget about namespaces.15:32
ihrachysthe bliss of ovn ;)15:33
ihrachyshaleyb: ok i +2d it then; there's a very minor comment about a comment, we can ignore it or pick up on respin.,15:37
haleybihrachys: thanks, i'll look and respin if necessary15:38
opendevreviewMerged openstack/os-vif stable/2024.2: Update .gitreview for stable/2024.2  https://review.opendev.org/c/openstack/os-vif/+/92835316:26
opendevreviewMerged openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2  https://review.opendev.org/c/openstack/os-vif/+/92835517:05
samcat116Hi all, is there anywhere in particular I should start debugging to figure out why hitting GET /ports?fields=id takes 10s to return? We have around 5k ports on our stack here using OVN. I'm running with 20 api_workers as well18:02
ihrachyssamcat116: how long does it take to list 100 ports? (does it scale linearly?)18:07
samcat11610 ports: 175ms... (full message at <https://matrix.org/oftc/media/v1/media/download/ASE4SBWzDqu7cUxipXvxvqTR2zAsWr9QrnN1M-TZ3sKws_YhPb_CY0Gyhi8buhqMATamJuwKpyKOntfmb7cJSstCeR3t5NUgAG1hdHJpeC5vcmcvQlNmU0ZWWG91Vk1wbWhwTXdaVkt2WlV2>)18:16
samcat116So decently linearly18:16
opendevreviewBrian Haley proposed openstack/neutron master: DNM: Test tempest port wait patch  https://review.opendev.org/c/openstack/neutron/+/92847221:18
opendevreviewMerged openstack/tap-as-a-service master: Doc: remove sphinxcontrib-*diag from doc dependencies  https://review.opendev.org/c/openstack/tap-as-a-service/+/92758421:19
opendevreviewMerged openstack/ovn-octavia-provider master: Fix member subnet id on a fully populated LB  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/92833521:24
opendevreviewMerged openstack/networking-bgpvpn master: Doc: remove sphinxcontrib-*diag from doc dependencies  https://review.opendev.org/c/openstack/networking-bgpvpn/+/92739022:24
ihrachyssamcat116: fyi your message didn't go through because you seem to use matrix bridge and it's truncated.23:55
ihrachysbut if it's linear, then... maybe it's expected? you have to serialize each port (even if it's just one id field), the work is constant per record.23:56

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!