Tuesday, 2025-03-18

opendevreviewJimin Shin proposed openstack/neutron master: Duplicated table lookup in extending port resource request  https://review.opendev.org/c/openstack/neutron/+/94465000:45
opendevreviewJimin Shin proposed openstack/neutron master: Extend port resource request when not using qos minimum rules  https://review.opendev.org/c/openstack/neutron/+/94475600:46
opendevreviewJimin Shin proposed openstack/neutron master: Extend port resource request only when using qos minimum rules  https://review.opendev.org/c/openstack/neutron/+/94475601:55
opendevreviewJimin Shin proposed openstack/neutron master: Check resource_request is required  https://review.opendev.org/c/openstack/neutron/+/94475602:01
opendevreviewOpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron/+/94482203:39
opendevreviewRodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove the usage of eventlet in the DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/94463406:55
opendevreviewRodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove eventlet from DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/94482606:56
opendevreviewRodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove eventlet from DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/94482606:56
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Delete a resource provider removed from the agent config  https://review.opendev.org/c/openstack/neutron/+/94405307:01
mnasiadkaralonsoh: if you need anything from Kolla for 944763 - let me know - we would be happy if this could be merged today07:02
ralonsohmnasiadka, I didn't see the execution yesterday. I thought the exiting results were all, my bad07:05
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Make the Logical_Switch_Port UP event more robust  https://review.opendev.org/c/openstack/neutron/+/94340407:11
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM == Test "neutron-tempest-plugin-openvswitch"  https://review.opendev.org/c/openstack/neutron/+/94261507:39
mnasiadkaralonsoh: I think all projects have a separate aarch64 pipeline07:59
danfaihi neutron, is there a way to speed up neutron-ovn-db-sync-util? While doing an initial sync we take like 2 seconds per port for adding it09:56
ralonsohdanfai, what version are you using? a logical_switch_port are you saying?09:59
danfairalonsoh: we are in yoga, OVN 22.12 ; It currently is in the loop for the lsp, yes10:00
ralonsohdanfai, yoga is a very old release no longer supported10:00
ralonsohthe last supported version is 2023.2, 3 releases newer10:00
danfaiok, I'll have a look whether there were changes to speed this up, but I fear this will be a huge pain point when migrating from Lxb to OVN, since you will have to sync initially. In our case this is 8h+ on 15k ports10:01
danfaiespecially since ports that are being deleted in neutron during the initial sync, we will have to restart the job10:02
danfai(they fail, since the revision number cannot be updated)10:02
ralonsohdanfai, but what section is the affected one?10:03
ralonsohwhere exactly it takes so much time?10:03
ralonsohwhere the Neutron ports are deleted??10:03
danfaiwe should be in that loop https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py#L117610:04
danfaithe ports being deleted is because we have the API still up and jobs running in the meantime. Since there mostly should not be any changes being done on the neutron DB, this should be a safe operation for us10:05
opendevreviewMerged openstack/neutron stable/2023.2: Fast exit if "segments" plugin is not loaded  https://review.opendev.org/c/openstack/neutron/+/94439910:06
opendevreviewMerged openstack/neutron stable/2024.1: Fast exit if "segments" plugin is not loaded  https://review.opendev.org/c/openstack/neutron/+/94439810:06
opendevreviewMerged openstack/neutron stable/2024.2: Fast exit if "segments" plugin is not loaded  https://review.opendev.org/c/openstack/neutron/+/94439710:06
ralonsohdanfai, I don't remember where this is documented but the environment should not be loaded during the sync process10:07
ralonsohso any work should be stopped and the Neutron API dedicated only to the sync10:07
danfaiSo do you think it would be safe to run the sync-util on a clone of the DB for example?10:08
ralonsohdanfai, why on a clone? you need to execute the sync in the environment because it makes changes in the Neutron and OVN databases10:10
danfaibecause there is no way we can afford an 8h+ downtime10:10
opendevreviewPierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required  https://review.opendev.org/c/openstack/neutron/+/94476310:20
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Isolate ``test_ovsdb_monitor.TestNBDbMonitor*`` FTs  https://review.opendev.org/c/openstack/neutron/+/94485811:04
ralonsohykarel, if you have 1 min ^^11:04
ykarelralonsoh, don't we also need to move these to mysql as those were reporting sqlite Foreign constraint errors?11:07
ralonsohykarel, sorry what test cases? I thought this was the affected class11:09
ralonsohahhhh11:09
ralonsohok ok ok11:09
ralonsohunderstood11:10
ykarelhttps://ac967958d7db9925bf11-8258bbe2bfc0c508066a865a71f46e18.ssl.cf1.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional/ed0c42a/testr_results.html11:10
ralonsohyeah, I'll it too11:10
ralonsohI'll do it too*11:10
ykarelack11:11
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN][FT] Use MySQL backend for ``TestNBDbMonitor*`` classes  https://review.opendev.org/c/openstack/neutron/+/94486011:15
zigoA customer of us has set 68 as MTU in his network on our public cloud. Result: neutron-dhcp-agent stack traces in loop...11:32
zigoSo it would be good if it could at least be not allowed in the Neutron policy.11:32
zigoralonsoh: Your thoughts? :)11:32
ralonsohno, that was already commented11:32
ralonsohwe have a document about the MTU min values11:32
ralonsohbut this is up to the user to set the correct value11:32
ralonsohI don't remember when that was discussed, let me check11:33
zigoThat'd be ok if at least the agent was not stack-tracing in loop and filling-up its log file.11:33
zigoI saw this bug opened: https://bugs.launchpad.net/neutron/+bug/198806911:33
ralonsohso we finally implemented a cap...11:35
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/875809/8/neutron/db/db_base_plugin_v2.py11:35
ralonsohok, so the problem you are mentioning should not happen then11:35
zigoOh, thanks a lot.11:37
zigoSo that patch limits the MTU minimum, right?11:37
zigoI'll backport it and deploy it then.11:37
ralonsohzigo, this is an API change11:38
ralonsohwe don't support this kind of backports11:38
ralonsohin U/S, maybe you are talking about your own repo11:38
zigoRight.11:39
zigoThough now, I see the IPV4_MIN_MTU in that patch is set to 68 for IPv4.11:40
opendevreviewLajos Katona proposed openstack/neutron master: If OVS Manager creation failes retry to set values  https://review.opendev.org/c/openstack/neutron/+/93911711:40
zigoWell, that's still would allow neutron-dhcp-agent to crash then!11:40
zigoI'm tempted to backport that patch, and artificially set IPV4_MIN_MTU to 1300 ...11:41
ralonsohwhat is the error in the DHCP agent?11:41
zigo(ie: as Debian specific patch)11:41
zigoHang on, sending log entry (need to anonymize ...)11:42
zigohttps://paste.opendev.org/show/b2VHDYtqMid27ksMx1H5/11:46
zigo(replaced UUIDs and tap names...)11:46
ralonsohok, I'll check it now11:47
zigoWe got 1500+ entry like that one per hour, for just *one* badly configured customer network.11:48
zigoFYI, that's a Caracal setup.11:48
zigoI've forced 1500 on the customer's network MTU, plus asked our support to contact the customer so that they don't do that again, but obviously that's not a long term solution.11:49
ralonsohzigo, do you happen to know what are the values passed in the call "rv = getattr(driver, action)(**action_kwargs)"11:52
zigoI don't. :/11:52
zigothat's a production cloud, I can't play with it too much.11:52
ralonsohzigo, does this network have multiple subnets?11:53
zigoThough it should be fairly easy to reproduce. (would take my CI about 3 or 4 hours to run though).11:53
zigoChecking...11:53
zigoA single 10.0.0.0/24 subnet.11:54
ralonsohok, I'll try to reproduce it locally11:55
zigoCheers.11:56
sahidhaleyb: o/13:08
sahidregarding https://review.opendev.org/c/openstack/neutron/+/94098313:08
sahidI'm not toally sure we should use context manager here, can you just confirm with me it is the direction you really want to take? 13:08
mnasiadkaralonsoh: sorry for chasing, any chance to get another review on https://review.opendev.org/c/openstack/neutron/+/944763 ?13:19
opendevreviewCandido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94461613:33
ralonsohmnasiadka, sure13:46
ralonsohmnasiadka, https://review.opendev.org/c/openstack/neutron/+/944763/3/neutron/agent/dhcp/agent.py#788 this comment is legit13:47
ralonsohyou can break after assigning need_ipv6_metadata13:47
ralonsohmnasiadka, if you respin the patch fixing it, I'll +2 intermediately13:51
ralonsohand we'll backport it ASAP13:51
haleybmnasiadka: i just commented in that patch as well, we should fix since it will be backported. i can do it quickly if you like13:58
ralonsoh"I'll +2 intermediately"... pffff I don't read what I write...13:59
haleybralonsoh: i read it "correctly" :)14:00
haleyb#startmeeting networking14:00
opendevmeetMeeting started Tue Mar 18 14:00:23 2025 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, haleyb, ralonsoh14:00
haleybo/14:00
obondarevo/14:00
slaweqo/14:00
ralonsohhello14:00
bcafarelo/14:00
mlavalle\o14:00
rubasovo/14:01
haleyb#announcements14:01
lajoskatonao/14:01
haleybWe are currently in week R-2 of Epoxy14:01
haleybRC1 was tagged and stable/2025.1 branch created14:01
haleybso anything critical should be cherry-picked to get into RC214:02
haleybi know there is the IPv6 metadata one14:02
ralonsohthe dhcp eventlet removal14:03
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/944826/214:03
haleybFinal RC deadline: March 28th, 2025 (R-1 week)14:03
haleybralonsoh: oh, the revert14:04
ralonsohyes, both patches14:04
ralonsohmust be in 2025.1 too14:04
lajoskatona+114:04
haleybglad we figured that out14:05
lajoskatonaafter half openstack collapsed, but in time anyway :-)14:05
haleybhttps://review.opendev.org/c/openstack/neutron/+/944634/2 is the parent change, got it14:06
haleybFinal 2025.1 Epoxy release: April 2nd, 202514:06
haleybSo please ping people here if you need reviews on critical gate fixes, and/or get them on the priority board14:07
haleybProject Teams Gathering (virtual): April 7th-11th, 202514:08
haleyb#link https://ptg.openinfra.dev/ to sign up14:08
haleyb#link https://etherpad.opendev.org/p/apr2025-ptg-neutron14:08
haleyb#link https://ptg.opendev.org/ptg.html for room assignments14:08
haleybI added two slots Tuesday, 4 on Wednesday and Thursday14:09
haleybdid not want to conflict with eventlet14:09
haleybplease add topics to the etherpad, think we should just push all RFE discussions until then14:10
haleybthat was all i had for announcements today, any others?14:11
lajoskatonathanks for PTG management :-)14:11
haleybthat's what you pay me for, oh wait... :)14:12
sahido/ late14:12
haleybo/14:12
haleyb#topic bugs14:12
haleybmlavalle was deputy last week, report is at14:12
mlavalle\o14:12
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/UA5Q7RUKIIWHZLYIEERYHB4T5NQANEPP/14:12
haleybso the high have been addressed14:14
haleyband the dhcp one is in flight14:14
haleyb#link https://bugs.launchpad.net/neutron/+bug/210187114:15
haleybUse of revision_number for router update on 2023.2 Bobcat cause error 50014:15
haleybthat was an interesting one, still waiting for the commands to reproduce14:15
mlavallewe are waiting for a response from submitter14:15
haleyband this one is incomplete as well14:16
haleyb#link https://bugs.launchpad.net/neutron/+bug/210204414:16
haleybNova-API problem - cannot list instances anymore14:16
haleybmight be config, i'm assuming it's not packages14:16
ralonsohbut do we have the Neutron APi exception?14:18
haleybralonsoh: no he never pasted it14:18
ralonsohok, we need it, for sure14:18
haleybyes. i'm watching as i want to make sure it's not a distro problem since it was ubuntu, but don't think it is14:18
haleybi did start seeing random batch_notifier unit test failures, one was in the metadata patch14:19
haleyb#link https://bugs.launchpad.net/neutron/+bug/210080614:19
haleybsaw them again i meant to say14:19
haleybralonsoh: can you see my comment in https://review.opendev.org/c/openstack/neutron/+/943212 ? maybe we can discuss after meeting14:20
ralonsohsure14:20
opendevreviewCandido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94461614:20
haleybany other bugs to discuss?14:21
ralonsohyes, two 14:21
haleybsure14:21
ralonsohhttps://bugs.launchpad.net/neutron/+bug/210209014:21
ralonsohI initially set it as low and no RFE14:22
ralonsohbecause that could be a bug, not a RFE14:22
ralonsohthe problem: with eventlet module, all workers (API, maintenance, rpc, periodic) were executed in the same process14:22
ralonsohnow this is not happening, but the OVN placement initial config is in the maintenance worker14:23
ralonsohbut anyone will expect that, if you restart the Neutron API, that will be executed14:23
ralonsohso the question is: should we move this to the Neutron API code?14:23
ralonsohnow, if we want to re-execute this initial config, we need to restart the maintenance process14:24
haleybralonsoh: it seems it was almost an unintended change and should be fixed14:25
ralonsohperfect, I had the same idea14:25
ralonsohthis is why I opened the bug14:25
ralonsohanyone else if free to comment on the LP bug, if needed14:26
ralonsohthe second one:14:26
ralonsohthis is the upper patch: https://review.opendev.org/c/openstack/neutron/+/94405314:26
ralonsohit needs to be backported14:26
ralonsohbut the first patch (singleton one) could be intrusive14:26
ralonsohI implemented that for the tests, but I can re-implement the tests for stable branches without it14:27
ralonsohso please, review these patches and I'll backport them (2nd and 3rd patch) without the 1st one14:27
ralonsohthat's all14:27
fricklerabout https://review.opendev.org/c/openstack/neutron/+/944763 / https://launchpad.net/bugs/210341714:28
fricklera) it is blocking kolla and we have no feasible workaround14:28
fricklerb) I wonder how that issue could have been detected within neutron14:28
ralonsohwe use metadata in the L3 agent14:29
ralonsohI don't know if we have any test using the dhcp one14:29
fricklerwell the issue in kolla isn't that metadata is broken, but that the dhcp agent is failing and thus instances don't get a dhcp response14:30
ralonsohthe patch needs a respin, but looks fine. Could be merged today and backported14:30
fricklerI'm not sure why that doesn't happen in a devstack setup14:30
ralonsohwe would need to check all our tempest tests14:31
haleybthe changes to the unit test would trigger it from waht i remember from an early PS14:31
lajoskatonathe dhcp failure is not related to the eventlet change?14:31
lajoskatonaor that is a parallel one<14:31
ralonsohnot this one14:31
lajoskatonaack14:31
haleybit's from my metadata ipv6 change14:31
haleybi fixed one bug but caused another14:32
lajoskatonathat's life :-)14:32
ralonsohhaleyb, will you push the new PS?14:32
lajoskatonathe dragon has endles new heads, and we had them just before release this time it seems14:33
haleybralonsoh: sure i can do right after meeting if i don't see an update14:33
fricklerI'm not sure whether running a (n-v) kolla job on neutron changes would be an option, or do you think that that would be too much?14:33
ralonsohyou can have your own neutron-master CI job14:34
ralonsohwith a daily execution14:34
fricklerwell we consume neutron from master anyway, so that would be just our normal jobs14:34
fricklerthe idea would be able to recognize issues before they are merged into master14:35
ralonsohyes but this is expensive, just when we are removing jobs14:36
ralonsohwhen was the last time Neutron introduced an error in kolla this big?14:36
ralonsohalso, as you said, you have your own jobs and we responded quick to this problem14:36
lajoskatonalike we have master oslo or main pyroute2 jobs to have quick alert14:37
slaweqfrickler we had in the past such kind of cross project non-voting jobs14:38
slaweqbut in order to save some infra resources we moved those jobs to periodic queue14:38
slaweqso maybe kolla-neutron job can be in periodic line too?14:38
slaweqand we are checking those periodic jobs weekly14:39
slaweqso IMO it is good tradeoff14:39
lajoskatona+1 for periodic weekly and let's check them on weekly CI meeting14:39
fricklerI think we have those already, but querying zuul is a bit slow for me right now14:41
frickleranyway, fine for me for now14:41
haleybok, we can discuss in CI meeting to see if there is any work here to help14:42
haleybthat was all the bugs i think14:43
haleybthis week jlibosva is the bug deputy, but i don't see him14:43
ralonsohI'll ping him later14:43
haleybcan someone ping him on slack channel, thanks14:43
haleybnext week is obondarev, is that good with you?14:43
obondarevyep14:44
haleybthanks!14:44
haleyb#topic community goals14:44
haleyblajoskatona: i don't see any neutronclient changes in-flight, so that's good :)14:45
haleybis it something to continue next cycle?14:45
haleybwe can come back to that14:46
lajoskatonayes, all open things merged, I have to go and find the next api topic to change to sdk14:46
haleyblajoskatona: ack, thanks14:46
haleybralonsoh: evenlet removal is next, i'll let you give status14:47
ralonsohyes, in bullet points14:47
ralonsohSRIOV: merged14:47
ralonsohDHCP: reverted due to missing backend in oslo.service14:47
ralonsohMacVTap: I need to check, but same ^^ problem14:47
ralonsohL3: no activity (I had bug fixes to push)14:48
ralonsohOVS: https://review.opendev.org/q/topic:%22bug/2087939%22+status:open14:48
ralonsohthat's all14:48
lajoskatonayes we said macvtap also uses oslo.services, so have to wait with it14:48
ralonsohyes14:48
haleybralonsoh: in your opinion, should be merge any/all of the ovs changes and get into 2025.1? i did have some comments out to sahid on one of the changes at least14:49
haleyb#link https://review.opendev.org/c/openstack/neutron/+/940983 - i need to look again14:50
ralonsohno, we don't need these changes in stable14:50
haleyback, that's what i thought, plus i don't want to cause breakeage14:50
ralonsohright14:51
haleybok, anything else for community topics?14:51
opendevreviewPierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required  https://review.opendev.org/c/openstack/neutron/+/94476314:52
haleyb#topic on-demand14:52
haleybwe already discussed the OVN placement bug14:52
ralonsohah yes, I added it in this list14:52
haleybralonsoh: regarding the DB bug you fixed (i can't find the patch) - is that something we need to backport?14:53
ralonsohwhich one?14:53
haleybhttps://review.opendev.org/c/openstack/neutron/+/94480314:53
haleybwould that affect a db migration?14:54
ralonsohpffff to be honest, I don't know why this was not affecting the migration14:54
ralonsohI'll push stable only patches for the affected ones14:55
ralonsohthat should be 2025.1 and 2024.214:55
ralonsohand 2023.114:55
haleyback, thanks14:55
* haleyb was thinking no one uses openstack? :-p14:56
haleybs/newer openstack14:56
haleybbut then i'm not a comedian14:56
haleybanyways, any other topics to discuss?14:57
ralonsohthat should be affecting the migration in the CI14:57
ralonsohbut as I said, I have no idea why is not...14:57
haleybi don't either14:57
haleybok, thanks for attending everyone, and ping here if there are critical things for RC214:58
haleyb#endmeeting14:59
opendevmeetMeeting ended Tue Mar 18 14:59:01 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:59
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.html14:59
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.txt14:59
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.log.html14:59
lajoskatonaBye14:59
ralonsohbye14:59
mlavalle\o14:59
slaweqo/14:59
priteauhaleyb: Could you please review the updated dhcp metadata patch? https://review.opendev.org/c/openstack/neutron/+/94476315:01
haleybpriteau: lgtm, thanks!15:01
ralonsohhaleyb, that was initially my fault: https://review.opendev.org/c/openstack/neutron/+/859111/1/neutron/db/migration/__init__.py15:04
ralonsoh(there are other errors, mine too)15:05
ralonsohI'll push the fixes15:05
haleyboops :( 15:06
opendevreviewRodolfo Alonso proposed openstack/neutron unmaintained/2023.1: [stable-only] Fix the Neutron milestones list  https://review.opendev.org/c/openstack/neutron/+/94487515:08
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2023.2: [stable-only] Fix the Neutron milestones list  https://review.opendev.org/c/openstack/neutron/+/94487615:10
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2024.1: [stable-only] Fix the Neutron milestones list  https://review.opendev.org/c/openstack/neutron/+/94487715:13
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2024.2: [stable-only] Fix the Neutron milestones list  https://review.opendev.org/c/openstack/neutron/+/94487915:15
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2025.1: [stable-only] Fix the Neutron milestones list  https://review.opendev.org/c/openstack/neutron/+/94488015:17
ralonsohhaleyb, not a single "open DB branch" without an error15:17
ralonsohpfffff15:17
haleybat least we're consistent, maybe we need to document it better15:17
ralonsohI has using my own previous patches15:18
ralonsohbut of course, I started adding errors and propagate them15:18
haleybfor example, i pushed patches yesterday to change and update jobs for 2025.2, the DB change falls in the same category. i really don't know if we document that somewhere or just rely on someone knowing what to do15:18
haleyb"here's what to do when we start a new release" type doc15:19
haleybmaybe it's there an i just haven't looked15:19
ralonsohor maybe better, some kind of UTs15:19
ralonsohthese patches should have 1) the new milestone, 2) the identification of the latest DB migration and 3) the current release15:20
ralonsohI think we can handle this in a UT class, let me check that15:20
ralonsohat least I'll create a LP bug now15:21
opendevreviewMerged openstack/neutron master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron/+/94482215:28
priteauhaleyb: the dhcp metadata fix has failed one check job already (not related, it's an OVN test). If I rebase it could you give it W+1 again so we don't have to wait another 1.5 hour?15:30
fricklermeh, completely unrelated ovn failure on the "kolla" fix already, is this a known issue? https://zuul.opendev.org/t/openstack/build/539ac70caed84f948edaa0382bd5623c does it make to abandon/restore the patch to get faster turnaround? or enqueue to gate directly?15:30
fricklerah, or what priteau says ;)15:31
haleybralonsoh: i added a topic to ptg as well so we don't forget15:31
opendevreviewPierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required  https://review.opendev.org/c/openstack/neutron/+/94476315:31
priteauralonsoh: haleyb: please W+1 again, thanks!15:31
haleybpriteau: done15:32
ralonsohhaleyb, sure thanks!15:44
ralonsohI've create this: https://bugs.launchpad.net/neutron/+bug/210353115:44
haleybralonsoh: ack, thanks, just need to work on a AI-bot to do all these changes for us :)15:46
ralonsohhaleyb, I think I know how to implement simple but effective UTs for this15:46
ralonsohI'll push a patch later this week (I need to focus on some bugs now)15:47
haleybyes, it can wait15:47
lajoskatonahaleyb, ralonsoh: this old doc should be updated also: https://docs.openstack.org/neutron/latest/contributor/policies/release-checklist.html15:47
haleybralonsoh: if you have time can you look at my comment in https://review.opendev.org/c/openstack/neutron/+/943212 ? i don't know why you changed from 2 seconds there15:48
ralonsohlajoskatona, actually the example provided is correct...15:50
ralonsohhaleyb, one sec15:50
haleyblajoskatona: oh, that's the list, we should make sure it is all up to date, for example with the CI changes we do each cycle15:50
lajoskatonaI always hated the job changes lots of possible mistakes (with my typing issues anyway....)15:51
ralonsohhaleyb, this time in BatchNotifier is the time.sleep() used to process and notify new events15:52
ralonsohthe shorted it, the faster we read and notify the new events15:52
ralonsohif no new events are added to the queue, no notification will be done15:52
ralonsohthis is why I reduced this interval15:52
ralonsohthe point is that we are monkey patching the self.notifier._notify method, but it could be called by other tests in parallel15:54
haleybralonsoh: so i think that the 0.2 is somehow not always long enough based on the assert 2 != 3 failure - does making it longer just help the test pass?15:55
haleyboh, i didn't know it could be called in parallel15:55
ralonsohI don't think this change will improve that15:55
haleybit didn't, just hid it for a week15:55
ralonsohwell, the other workers are executed in other processes15:56
ralonsohso that is not true... my bad15:56
ralonsohhaleyb, why if we are adding 20 events in this test, we check call_count=2??15:58
haleybralonsoh: there is a comment below it - events are added but only triggers 2 calls in the notifier, which makes sense15:58
ralonsohupssss, ok, this test was relying on this 2secs interval15:58
ralonsohI think this is wrong... or at least prone to errors in slow envs (CI)15:59
haleybyes, the 2 sec comment doesn't match the code, was changed in the evenlet change15:59
haleybi moved to 0.2 but can put right back to 215:59
ralonsohthe method ``_batch_notifier_dequeue`` should enqueue the events in a list or something15:59
ralonsohand then we need to check how many events have been notified15:59
ralonsohthis is more reliable16:00
ralonsohin L51, we are getting the pending events16:00
ralonsohself.notifier._pending_events.get()16:00
ralonsohthis is where we can add a list to store them16:00
ralonsohand then count them in an active wait16:01
ralonsohwe don't need L60 check now16:01
ralonsohjust wait_until_true(lambda: len(list_events) == 20)16:01
haleybralonsoh: isn't that was the test below does kind-of?16:02
ralonsohI was checking that too16:02
ralonsohyes, that's right16:02
ralonsohso ``test_queue_event_multiple_events_notify_method`` makes no sense16:03
ralonsohwe can remove it16:03
haleybralonsoh: ack, since you had added that back in 2019 i figured i'd let you make the call, commit 8b7d2c8a93fdf69a828f14bd527d8f132b27bc6e16:05
ralonsohhaleyb, that was just a refactor16:08
ralonsohtrying to replicate what was done before16:08
ralonsohbut this test is unnecessary16:08
haleybralonsoh: i can just remove it all, easy enough16:08
ralonsohperfect16:08
ralonsohI need to leave now, I'll connect again in some hours16:09
ralonsohhaleyb, https://review.opendev.org/q/Ie391af5a3b226cbd33f7162a3c970d636fcdf1da16:12
ralonsohif you have 1 min16:12
opendevreviewDong Ma proposed openstack/ovn-bgp-agent master: Add the support of create kubernetes resource  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/93745716:46
haleybzigo: rodolfo had opened https://bugs.launchpad.net/neutron/+bug/2103514 for the mtu issue you saw, can you check that and provide any more info? thanks17:14
*** dmellado0755393733 is now known as dmellado07553937317:14
zigohaleyb: will do tomorow, got all in a private gitlab issue.17:16
opendevreviewMaor Blaustein proposed x/whitebox-neutron-tempest-plugin master: [DNM] Test metadata rate limiting - master devstack ovn  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94492118:00
opendevreviewCandido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94461618:29
opendevreviewMerged openstack/neutron stable/2024.1: [OVN] Do not delete twice the agent from the cache  https://review.opendev.org/c/openstack/neutron/+/94439418:36
opendevreviewMerged openstack/neutron stable/2023.2: [OVN] Do not delete twice the agent from the cache  https://review.opendev.org/c/openstack/neutron/+/94439618:36
opendevreviewMerged openstack/neutron master: Spawn IPv6 metadata proxy only when required  https://review.opendev.org/c/openstack/neutron/+/94476319:58
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2025.1: Spawn IPv6 metadata proxy only when required  https://review.opendev.org/c/openstack/neutron/+/94494320:05
opendevreviewJakub Libosvar proposed openstack/ovn-bgp-agent master: Use OS_TEST_PATH evironment variable to define tests location  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/94494520:26
opendevreviewBrian Haley proposed openstack/neutron master: Remove flaky batch notifier unit test  https://review.opendev.org/c/openstack/neutron/+/94495021:08
ralonsohhaleyb, what is SUT?21:08
haleybralonsoh: system under test, i couldn't think of anything better21:17
haleybi can change it21:17
ralonsohno no, just asking21:44
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Make the Logical_Switch_Port UP event more robust  https://review.opendev.org/c/openstack/neutron/+/94340421:45
opendevreviewBrian Haley proposed openstack/neutron stable/2024.2: Optionally configure IPv6 metadata address  https://review.opendev.org/c/openstack/neutron/+/94449622:01
opendevreviewMerged openstack/neutron master: Revert "[eventlet-removal] Remove the usage of eventlet in the DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/94463423:49

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