Wednesday, 2026-09-02

gmaangibi: sean-k-mooney : this is fix for the live migration task leaking https://review.opendev.org/c/openstack/nova/+/100338602:02
*** bauzas4 is now known as bauzas02:08
opendevreviewGoutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares  https://review.opendev.org/c/openstack/nova/+/98963305:19
opendevreviewAdam McArthur proposed openstack/nova master: Use safe allocation deletion on instance delete  https://review.opendev.org/c/openstack/nova/+/100320806:12
*** zseguin is now known as Guest1691406:31
*** bauzas0 is now known as bauzas07:43
*** erlon8 is now known as erlon09:43
gibican I get an core eye on https://review.opendev.org/c/openstack/nova/+/1003245 it is a functional test stabilization10:02
sean-k-mooneyso the intet is to set it to a largere value later but we are settign it to 10 for now so that if we do leak it does not cause the run to fail10:12
sean-k-mooneyi see in https://review.opendev.org/c/openstack/nova/+/1003266/1/nova/tests/functional/regressions/test_bug_1888395.py your bumping it to 300 and hten claping it to 10 on the tests that have know issues10:15
sean-k-mooneyany that are leaking a thread will timeout and you can clamp them until its fixed10:16
sean-k-mooneygibi: we can technially start deleting evnetlet in like a weak to eliminate those leaks :)10:17
sean-k-mooneygibi: by the way did you notice that the threading functional test now run in half the time of the eventlet ones10:19
sean-k-mooneyoh nope10:20
sean-k-mooneythats the non funtionla treadign tests10:20
gibisean-k-mooney: we cannot delete them until post 2027.1 10:21
sean-k-mooneywe technially can10:22
sean-k-mooneybut i know we are givign a very long tail in nova10:22
gibisc-tmp-lighbits-rhoso-certification10:22
gibihttps://governance.openstack.org/tc/goals/selected/remove-eventlet.html#completion-criteria10:22
gibiu(2027.1) Deprecate the Eventlet support. To have a SLURP target release supporting both the old Eventlet and any new concurrency mode, this release keeps the Eventlet support.10:22
sean-k-mooneythose are the letes tg we can do those10:23
sean-k-mooneynot the first time for each milestone10:23
sean-k-mooneyseveral service just remove eventlet with no opertunity to have a singel slurp release that ran both 10:23
gibibut I think what is written in the goal is there because we wanted to do it that way :)10:24
sean-k-mooneywe did im just saying if it continue to be a maintiance isseu we can change that planb10:24
sean-k-mooneyon the ohter hand10:24
sean-k-mooneyif the eventlet test find leaks that we dont see in threaded10:25
sean-k-mooneywe probably shoudl fix those anyway10:25
gibiyeah I haven't looked into the eventlet hangs in that patch10:25
gibibut I will10:25
opendevreviewBalazs Gibizer proposed openstack/nova master: Stabilize _test_interface_attach_and_detach  https://review.opendev.org/c/openstack/nova/+/100345210:47
gibisean-k-mooney: bauzas: ^^ another functional stabilization patch10:47
opendevreviewBalazs Gibizer proposed openstack/nova master: [functional]Do not patch req-id generation  https://review.opendev.org/c/openstack/nova/+/100302413:21
gibicores this is another stabilization ^^13:21
stephenfinsean-k-mooney: did you already bring up https://review.opendev.org/c/openstack/releases/+/1003257?14:16
stephenfinhttps://review.opendev.org/c/openstack/releases/+/1003311 is blocked by that14:17
sean-k-mooneysorry no Uggla bauzas ^ we need to release os-vif again 14:32
sean-k-mooneyelodilles: ^ fyi14:33
Ugglasean-k-mooney ok I have seen the patches14:33
elodillessean-k-mooney: nova team needs to agree on FFE and an RFE needs to be requested from requirements team, otherwise LGTM14:41
sean-k-mooneythe config bug is a reguress intoduced in this cycle os i think it would qualify for a FFE adn enve after RC1 but idealy we do it before we do it14:48
gibiI'm OK from nova perspective to accept this os_vif fix as FFE 14:52
gibihttps://review.opendev.org/c/openstack/nova/+/1003266/1/nova/tests/fixtures/conf.py#7314:52
gibithis is being the fix14:52
opendevreviewBalazs Gibizer proposed openstack/nova master: [DNM]reproduce "database is locked" error  https://review.opendev.org/c/openstack/nova/+/100355415:37
gibisean-k-mooney: ^^ finally after 2days and many deep rabbit holes this reproduces the DB locking issue pretty regularly to me locally15:38
gibithere is something called checkpointing the WAL 15:39
gibithat happens after the last DB connection is closed 15:40
gibihappens outside of the db context manager15:40
gibiand sqlite takes a DB write lock for it15:40
gibias we constantly open and close DB connections there is plenty of, very short, window when there is a last-connection-closed situation15:41
gibiand if we are unlucky the next connection is a write transaction that hits within the window of the WAL checkpointing and seeing the DB as locked15:41
gmaangibi: https://review.opendev.org/c/openstack/nova/+/1003386 is green to fix the leaking task. can you rebase your manager_shutdown_timeout=300 change to this and we can see what all are fixed with this 15:42
gibigmaan: on my list still for today15:42
gmaanthanks15:42
melwittso that per something lock change did not help huh?15:42
gibimelwitt: it helps15:44
gibiwe need to serialize writes15:44
gibibut15:44
melwittoh ok15:45
gibithere is this secondary case when sqlite takes a DB write lock15:45
gibioutside of a write transaction15:45
gibithe case being, the last connection to the DB is closed.15:45
gibiso the immedate fix is, do not allow such situation to happen :)15:45
gibii.e. keep a connection open during the test15:46
melwittah, yeah. that's how the in-memory db worked so it didn't come up in the past15:46
gibiyes in memory DB used a StaticPool to have only a single connection to a DB all the time15:46
melwittright15:47
gibithe file based uses a NullPool15:47
gibimeaning one connection per transaction15:47
gibithe StaticPool is not good for us in threading as that allows two parallel transaction to overlap on that single global connection 15:48
gibibut NullPool + WAL triggers this edge case of checkpointing the WAL15:48
gibimy learning from the last two days: DB engines are complicated beasts 15:49
melwittyes they are :( in my limited experience15:49
sean-k-mooneygibi: nice find15:56
sean-k-mooneythe checkpointing this vagly rings a bell but only in that i think i came across that at some poihnt15:57
sean-k-mooneybut not that it happend on connection close/open15:57
sean-k-mooneykeeping the conenction open during the test is proably fine if we can do that cleanly15:58
gibiI think this is part of the maintenance of the WAL itself15:58
gibi> cleanly15:58
gibiworking on it :)15:58
sean-k-mooneyi was thinking of some kind fo per test singelton that we setup and tear down15:59
sean-k-mooneythe impornat thing is you have a repoducer that does not need an entire ci run now16:00
gibiyepp by running with timeout=0 in the DB url (which is busy_timeout for SQLite) I can trigger the issue locally in my machine pretty frequently 16:03
gibiso I can test a fiz16:03
gibifix16:03
sean-k-mooneyif you push one ill let it run on my mac min for an hour or two in a loop while we wait on ci16:04
gibiyeah working on the cleaniness16:05
gibiof the fix16:05
gibibut I saw having a connection open removing the issue locally16:05
gibiclosing the connection is a pain as the place where we need to open it is before the fixture setUp so I cannot register a function via addCleanup. Probably I need to create just an additional fixture for the connection and hope that opening the extra connection a bit after the DB creation is still OK to fix this16:09
sean-k-mooneyyou can just directlly add it to tearDown16:10
sean-k-mooneyif needed16:11
opendevreviewBalazs Gibizer proposed openstack/nova master: [func]Avoid WAL checkpointing  https://review.opendev.org/c/openstack/nova/+/100358617:46
gibisean-k-mooney: ^^17:46
sean-k-mooneycool, the DNM hung when i ran it so ill start running that17:47
sean-k-mooneydo you need to handel oterh escptions form the opertunistic test fixture17:48
sean-k-mooneyand or only do this when we are uing squlight17:49
sean-k-mooney*sqlite17:49
sean-k-mooneyi guess no17:49
sean-k-mooneybecause you rusign it from _bind_database_fixture_to_file_wal_sqlite17:49
opendevreviewBalazs Gibizer proposed openstack/nova master: [func test]Catch hanging task at graceful shutdown  https://review.opendev.org/c/openstack/nova/+/100326617:50
gibiyepp it is sqlite specific17:50
gibigmaan: cherry picked https://review.opendev.org/c/openstack/nova/+/1003266 top of you fix and removed the TODOs, I will check back on the result tomorrow17:51
gibiaaand I drop for today o/17:51
sean-k-mooneyo/17:51
gmaangibi: thanks and o/17:56
sean-k-mooney functional-py313-threading: OK (573.29=setup[8.02]+cmd[0.01,564.34,0.93] seconds)17:59
sean-k-mooneyok im going to run that with --until failure for an hour or so18:00
opendevreviewBalazs Gibizer proposed openstack/nova master: [func test]Catch hanging task at graceful shutdown  https://review.opendev.org/c/openstack/nova/+/100326618:49

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