Tuesday, 2025-03-25

opendevreviewMerged openstack/nova master: unified limits: discover service ID and region ID  https://review.opendev.org/c/openstack/nova/+/94350701:33
opendevreviewMerged openstack/nova stable/2024.1: Reproducer for bug 2098892  https://review.opendev.org/c/openstack/nova/+/94265301:33
opendevreviewMerged openstack/nova stable/2024.1: libvirt: Fix regression of listDevices() return type  https://review.opendev.org/c/openstack/nova/+/94265401:33
opendevreviewMerged openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise  https://review.opendev.org/c/openstack/nova/+/94502804:35
mikalsean-k-mooney: I added a section to the PTG etherpad for the SPICE VDI next steps. I am not entirely sure it needs a big discussion, but your thoughts would be welcome.08:38
opendevreviewsean mooney proposed openstack/nova stable/2025.1: wrap wsgi_app.init_application with latch_error_on_raise  https://review.opendev.org/c/openstack/nova/+/94543910:02
opendevreviewsean mooney proposed openstack/nova stable/2024.2: wrap wsgi_app.init_application with latch_error_on_raise  https://review.opendev.org/c/openstack/nova/+/94544010:04
opendevreviewsean mooney proposed openstack/nova stable/2024.1: wrap wsgi_app.init_application with latch_error_on_raise  https://review.opendev.org/c/openstack/nova/+/94544110:05
opendevreviewsean mooney proposed openstack/nova stable/2023.2: wrap wsgi_app.init_application with latch_error_on_raise  https://review.opendev.org/c/openstack/nova/+/94544210:06
sean-k-mooneymikal:ack, i think the vdi enhancments are reasonable, you could files a specless blueprint for it now and added it to todays irc meeting we can see if we can get it approved so you can pick up where you left off10:26
*** ykarel_ is now known as ykarel11:12
elodillessean-k-mooney: regarding yesterday's ping about backportability of the 3 patches till caracal ( https://review.opendev.org/c/openstack/nova/+/918089/3 ): to me it looked OK to backport, but reading dansmith's opinion - he has more insight in this, so - it's completely on nova team decision whether an exception to backport this should be granted or not o:) (based on the discussion, backporting to 13:04
elodillesprior version than Caracal is not possible in my opinion).13:04
ratailorelodilles, sean-k-mooney, gibi could you please review these, one more +2 is required https://review.opendev.org/c/openstack/nova/+/933107 https://review.opendev.org/c/openstack/nova/+/873901 https://review.opendev.org/c/openstack/nova/+/938054 ?13:09
elodillesratailor: i don't have +2 right on master branch o:)13:14
ratailorelodilles, ack. no problem. you can provide your suggestion, if you want to. Thanks! :)13:15
*** haleyb|out is now known as haleyb13:15
elodilles:)13:15
sean-k-mooneyratailor: sure, i need to context switch to somethign else shortly but +2w on https://review.opendev.org/c/openstack/nova/+/933107, im already +2 on https://review.opendev.org/c/openstack/nova/+/938054 so that needs someone else. ill quickly review https://review.opendev.org/c/openstack/nova/+/87390113:25
ratailorsean-k-mooney, sure. Thanks!13:26
sean-k-mooneymy commnets on test coverage are still open on https://review.opendev.org/c/openstack/nova/+/873901 but no one has rasied a concern in 3 months so im sort of inlcined to say we can add more later if needed13:27
sean-k-mooneyratailor: what ill do is the following. ill elevate form +1 to +2w but it would be nice if you could submit a followup after this merges for the happy path test i called out and other nits.13:29
ratailorsean-k-mooney, sure. I will do.13:30
opendevreviewribaudr proposed openstack/nova master: FUP Remove unnecessary PCI check  https://review.opendev.org/c/openstack/nova/+/94410513:34
opendevreviewribaudr proposed openstack/nova master: FUP improve comment accuracy and variable naming for tag removal  https://review.opendev.org/c/openstack/nova/+/94312413:34
opendevreviewribaudr proposed openstack/nova master: FUP Add a warning to make non-explicit live migration request debugging easier  https://review.opendev.org/c/openstack/nova/+/94413313:34
opendevreviewribaudr proposed openstack/nova master: FUP Update pci-passthrough and virtual-gpu documentation  https://review.opendev.org/c/openstack/nova/+/94415313:34
opendevreviewribaudr proposed openstack/nova master: FUP: Improve libvirt fixture for hostdevs  https://review.opendev.org/c/openstack/nova/+/94523213:34
opendevreviewribaudr proposed openstack/nova master: FUP improve and add integration tests for PCI SR-IOV servers  https://review.opendev.org/c/openstack/nova/+/94410613:34
elodillesbtw, if any nova core is ready for a 10 sec review (of a bot generated patch): https://review.opendev.org/c/openstack/nova/+/94489013:38
bauzaselodilles: done13:39
elodillesthanks \o/13:48
dansmith...there must be some sort of magic to get failing gabbit tests to actually show me logs...14:04
gibidansmith: does OS_DEBUG=1 helps?14:07
dansmithit does not14:07
gibi:/14:07
gibiit was too long ago when last time I debugged gabbit to remember14:07
dansmithyeah, I've been tearing through infrastructure trying to hack it to give me logs or see why it's swallowing it,14:08
dansmithbut it's just very focused on the gabbit result14:08
dansmithglance functional tests are sort of similar.. really really hard to get the backend logs when there's a failure14:08
dansmithsuper annoying14:08
gibiI agree14:14
sean-k-mooneyi was going to suggest the same OS_DEBUG=1 i confirmed it is allowed in the tox config so its not that either14:16
sean-k-mooneyits usign the normal log fixtures but it also has 2 addtional ones for error and warning 14:18
sean-k-mooneyhttps://github.com/openstack/placement/blob/master/placement/tests/functional/base.py#L54-L5814:18
sean-k-mooneyso i think its those last two that are the problem14:18
dansmithyeah, I'm about to just repro the gabbit that is failing in python so I can effing see the problem14:18
sean-k-mooneyi woudl ty comemntign out lines 57 and 5814:18
sean-k-mooneyand see fi it woks with os_debug then 14:18
dansmithalready tried :)14:19
sean-k-mooneywell you can do the tried and true Raise RuntimeError instead of logging14:20
dansmithI have no idea where it's failing14:22
sean-k-mooneyhttps://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/capture.py#L40-L6214:22
dansmithit's a 500, which should be logging lots14:22
sean-k-mooneyoh gabbit also has its own fixtures with its own logging config. it does include that however14:24
sean-k-mooneyhttps://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/gabbits.py#L6214:24
dansmiththere are multiple layers of log interception in placement, and also in gabbi yeah14:24
dansmithI'm wondering if gabbi has changed in some way and left placement stuck14:25
dansmithto be clear, I've tried to mangle that capture module and I'm not sure it's ever even getting hit14:25
dansmithI can define error, warning, etc on there and raise and nothing changes14:25
dansmithnot sure if that's because it ends up with another nameless 500 or what14:26
sean-k-mooneywell if you are looging and its intercepted it should show up in one fo those fixtures14:27
dansmithto be clear, I'm not logging14:27
dansmiththere's a gabbit test that now fails with 500 after a change I made14:28
dansmithand I'm trying to figure out what the 500 is14:28
sean-k-mooneyoh you want ot see that ok14:28
dansmithbut I agree, it should be going through that fixture14:28
sean-k-mooneyso it has to be realted to this block https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/gabbits.py#L62-L7114:28
dansmithI mean, you'd think, but there are similar fixtures also in functional/base14:30
dansmithand in gabbi itself14:30
sean-k-mooneyoh you think that the fact we are inheriting form the gabbit testcase might be altering the behavior14:31
sean-k-mooneylooking at git blame https://github.com/openstack/placement/commit/fcd1e538d9b7d315cb3f74c83f1a9e4ddcab180e14:31
sean-k-mooneyit same like there was a lot of log output in the past and they added thsi handelign ot silance some of that14:31
dansmithI removed all those fixture setups in gabbits.py and no change14:31
dansmithright, I'm sure it's the attempt to make it pretty, but it has made it completely un-debuggable, AFAICT14:32
sean-k-mooneyi proably shoudl be doing somethign else bug you peaked my interest14:32
sean-k-mooneydo you have a patch i can pully or aplly and see if i can replicate it14:32
dansmithI can push it up14:33
opendevreviewDan Smith proposed openstack/placement master: Reproduce bug 2104040: allocate in over-capacity  https://review.opendev.org/c/openstack/placement/+/94546414:34
opendevreviewDan Smith proposed openstack/placement master: Fix placement allocate while over-capacity  https://review.opendev.org/c/openstack/placement/+/94546514:34
dansmithsean-k-mooney: ^14:34
sean-k-mooneythe secodn one is causign the 500 ya14:35
dansmithmaybe the actual thing failing will get hit by a tempest test and I can see what the effing problem is :)14:35
dansmithyeah14:35
sean-k-mooneywell placmeent does not use eventlet so in theory i can also run this under a debugger in vscoded and set a breakpoint14:36
sean-k-mooneyi have never tried that with placment but i have got that to work wiht some of watchers unit tests14:37
dansmithif I knew where to set a breakpoint I could do the same :)14:37
sean-k-mooneyyou can make the debugger tirgger on uncaught excetpions14:37
sean-k-mooneyim going ot make sure i can repoduce the fialure first and then ill try something more fancy14:38
dansmiththanks, maybe I've got tunnel vision on something14:39
sean-k-mooney... we still have not merget the patch to move form psycopg2 to psycopg2-binary...14:44
sean-k-mooneyoh we didnt propose that ot placment14:44
sean-k-mooneyill fix that later14:44
sean-k-mooneyif we use psycopg2-binary instead we dont need the postgress development headers to be able to compile it14:45
sean-k-mooneydansmith: so i ran the functional tests and everything passed 14:47
sean-k-mooneyoh nevermind14:47
sean-k-mooneythat with master i have not applied you change yet14:47
sean-k-mooneyi did see "TransactionFactory already started, not reconfiguring." pirnted once or twice which is a bit suss but it does nto seam to be breaking anything14:48
dansmithmaster passes for me too :)14:49
dansmithI think I've just guessed the thing it's failing on by trial and error, which is good, but it's like debugging in the dark14:49
sean-k-mooneyso i have output14:50
sean-k-mooneyand two failed testcases14:50
sean-k-mooneyhttps://paste.opendev.org/show/baZsKMeiO9mOxyGz2OlY/14:51
dansmith...right14:51
dansmiththat's just gabbit output14:51
dansmithnot the logging from the wsgi app to show you where the 500 was14:51
sean-k-mooneyah you want the api logs form the service right14:51
dansmithyeah, so I can see, you know, the *actual* problem14:51
sean-k-mooneyright well now that i know which tests are failing i can see if i can get more output sicn ei an just target those specific tests14:53
Ugglasean-k-mooney, do you think we should have a cross team nova-watcher session at the PTG ?15:05
sean-k-mooneysigh... the way we dynmically load teh gabit tst means that they are not discoverd wehn we use pytest and the way we alias the global fixtures module with our own breaks unittests discoveray15:05
sean-k-mooneyUggla: am we could the topics i wanted to raise are not only relvent to watcher but it does not need to be super formal15:06
dansmithsean-k-mooney: yep, already tried that, but you can use testtools directly, just not for a specific test. you have to run all the gabbit tests15:07
sean-k-mooneydid you try the stestr pdb supprot?15:07
sean-k-mooney... AttributeError: module 'placement.tests.functional.test_api' has no attribute 'allocations-bug-1778743_post_multiple_allocations'15:10
sean-k-mooneyright 15:10
Ugglasean-k-mooney, ok so I will not create a specific time slot only for watcher and will "distribute" the topic in the agenda where it fits best. Is that ok ?15:11
sean-k-mooneysounds good15:11
sean-k-mooneydansmith: so passing --pdb to stestr didnt help either how fun15:12
dansmithlovely15:13
opendevreviewDan Smith proposed openstack/placement master: Fix placement allocate while over-capacity  https://review.opendev.org/c/openstack/placement/+/94546515:16
sean-k-mooneydansmith: https://github.com/cdent/gabbi/commit/2469b1617fde2ee62f42ef48fc38a7d075c1dd62#diff-af026a8f8ce5b1d6bf2c2b9a33c71ba0566feb828ca0fbc8ec4f3970c2835c7515:16
sean-k-mooneyappreently you can mark a test as verbose15:16
dansmithand that lets logs go?15:17
sean-k-mooneynot exactly https://paste.opendev.org/show/bI2SFFiDmfx51VXu7CrD/15:19
sean-k-mooneyyou do get more output15:19
dansmithunhelpful output15:19
sean-k-mooneyits jsut increasing the verbosity of the client15:20
dansmithyeah15:26
sean-k-mooneyok i have logs but i need to change code15:33
sean-k-mooneyill make this configuable in a env var15:34
sean-k-mooneytldr set this to false https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/capture.py#L5515:34
dansmithWAT15:35
dansmithset to false?15:35
sean-k-mooneyyep to turn off the log capture and allow it to print to stderr15:35
dansmithI have commented out the usage of that thing entirely and I still don't get logs15:35
dansmithdo you also have to disable the stdio capture?15:36
sean-k-mooneyi also invoked it liek this wiht a few other changes 15:36
sean-k-mooneyOS_DEBUG=1 OS_LOG_CAPTURE=1 tox -e functional -- --failing15:36
dansmithokay are you going to push up a change so I can see what all?15:36
sean-k-mooneyyep15:36
dansmithaight15:37
sean-k-mooneyi mean its just this https://termbin.com/gj5q15:37
sean-k-mooneybut not all of that is relevent15:37
sean-k-mooneyill past you the output so you can review15:38
sean-k-mooneythen ill figure out what bits actully matter15:38
sean-k-mooneyhttps://termbin.com/zacx15:39
sean-k-mooney File "/home/smooney/repos/placement/placement/objects/allocation.py", line 262, in _check_capacity_exceeded15:40
sean-k-mooney    prev_used = prev_usage[alloc.resource_provider.id][rc_id]15:40
opendevreviewDan Smith proposed openstack/placement master: Reproduce bug 2104040: allocate in over-capacity  https://review.opendev.org/c/openstack/placement/+/94546415:40
opendevreviewDan Smith proposed openstack/placement master: Fix placement allocate while over-capacity  https://review.opendev.org/c/openstack/placement/+/94546515:40
sean-k-mooney                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^15:40
sean-k-mooneyKeyError: 015:40
dansmithOS_LOG_CAPTURE=1 sets capture_logs=True on oslo right?15:41
sean-k-mooneyi need to see if thats actully needed but proably 15:41
dansmithvery confusing if we need to set that on the parent *and* =False on the child.. I suspect one of those and not the other is to blame15:42
sean-k-mooneyok so that is not relevnet15:42
sean-k-mooneyi can set it to 0 and it still work15:42
sean-k-mooneyi was gong to use that to contole it however15:42
dansmithokay, isn't that capture_logs flag telling oslo to capture the logs in memory so they can be reported with the test failure?15:43
sean-k-mooneyso instead of hardcoding this to true defualt that to 0 or 1 i dont know what makes the most sense and allow you to override it15:43
dansmithI'm not sure why we'd ever want that to be false unless the reporting is wrong15:43
sean-k-mooneyi need to read the related code to answer properly but this is the relevnet code https://github.com/openstack/oslotest/blob/1fe445863e124f8a10c1496fb8244c745e546b21/oslotest/log.py#L35-L9115:45
sean-k-mooneythis is why i have not pushed a patch yet im trying to load context and then figurout what the correct behavior should be before commiting and pushing15:46
Ugglanova meeting in aound 15mn.15:47
sean-k-mooneydansmith: by hardcodign it to ture we were alsways addign the fake loonger15:48
sean-k-mooneywhich make shte logs aviable in the tests 15:48
dansmithright, but that's the intent so it gets reported to the test runner so the runner can report the test fail with logs right?15:48
sean-k-mooneybtu im not sure if that will attach them to the tests to print on output15:48
dansmithyeah, idk15:48
dansmithso many layers and years of crust, I'm not even sure how it's supposed to work15:49
sean-k-mooneysince we know what to flip we can easly expose that bool as an env var in any case15:49
sean-k-mooneydansmith: so its  wrapping a logging fixture form fixtures and nuke_handeler is set to true15:51
sean-k-mooneyhttps://github.com/testing-cabal/fixtures/blob/master/fixtures/_fixtures/logger.py#L39-L4015:51
sean-k-mooneywhich prevent it going to stdout15:52
sean-k-mooneydansmith: i have not trast all the code it possibel we ar attachign the logs as an addtional attachment to the test15:53
dansmithright, but I thought things like testr were doing their own capturing of the logs, as long as they don't get swallowed so they can be reported per-test (in the "logging" section)15:53
sean-k-mooneythere is an stester flag to print addtional attachments15:53
dansmithright, unittest does that with addSection() or whatever15:53
sean-k-mooneyya let me see if passing that flag helps15:53
sean-k-mooneyoh that just for succesful test "--all-attachments" 15:54
dansmithyeah15:55
opendevreviewMerged openstack/nova master: Fix case sensitive comparison  https://review.opendev.org/c/openstack/nova/+/93310715:56
opendevreviewMerged openstack/nova master: Fix case-sensitivity for metadata keys  https://review.opendev.org/c/openstack/nova/+/87390115:57
opendevreviewMerged openstack/nova master: Update master for stable/2025.1  https://review.opendev.org/c/openstack/nova/+/94489015:57
Uggla#startmeeting nova16:00
opendevmeetMeeting started Tue Mar 25 16:00:20 2025 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
UgglaHello everyone16:00
masahitoo/16:01
elodilleso/16:02
gibio/16:02
Ugglaawaiting a moment for people to join.16:02
dansmitho/16:02
bauzas\o (in another meeting)16:03
Uggla#topic Bugs (stuck/critical)16:03
Uggla#info No Critical bug16:03
Uggla         #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster16:04
Ugglaanything about bugs ?16:04
Uggla#topic Gate status16:05
Uggla#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs16:06
Uggla#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:06
Uggla#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status16:06
Uggla#info Please look at the gate failures and file a bug report with the gate-failure tag.16:06
Uggla#info Please try to provide meaningful comment when you recheck16:06
Ugglaanything about the gate ?16:06
Ugglaseems not.16:07
Uggla#topic Release Planning16:07
Uggla#link https://releases.openstack.org/epoxy/schedule.html16:08
Uggla#info Nova deadlines are set in the above schedule16:08
Uggla#link https://etherpad.opendev.org/p/nova-epoxy-rc-potential16:08
Uggla#link https://releases.openstack.org/flamingo/schedule.html16:08
Uggla#info Remaining post RC1: update min servion version for a SLURP or non-SLURP release : https://review.opendev.org/c/openstack/nova/+/944018/16:08
Uggla#info Nova Flamingo deadlines will be discussed at the PTG.16:09
UgglaWe are almost good for Epoxy release.16:09
elodillesnote that this week is the week of Final RC for 2025.1 Epoxy :)16:09
Uggla#topic Review priorities16:10
Uggla#info Flamingo priorities will be discussed at the PTG.16:10
Uggla#topic PTG planning16:10
Uggla#info Next PTG will be held on Apr 7-1116:11
Uggla#link https://etherpad.opendev.org/p/nova-2025.2-ptg16:11
UgglaPlease add the topics you want to discuss in the pad.16:11
Uggla#topic Stable Branches16:12
Uggla#info stable gates seem to be healthy16:12
Uggla#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:12
Ugglaelodilles, if you want to add something please go ahead.16:13
elodillesyepp, one thing maybe:16:13
elodilles#info stable/2025.1 branch was cut for nova as well last week16:13
elodillesthat's all from me16:13
elodillesback to you Uggla 16:13
Ugglathanks elodilles 16:13
elodillesnp16:13
UgglaI skip the vmwareapi 3rd-party CI efforts Highlights as fwiesel is ooo this week.16:15
Uggla#topic Open discussion16:15
Ugglaanything to discuss ?16:16
keerthivasan86[m]Just quick question why https://bugs.launchpad.net/nova/+bug/1766387 ( why tx_queue_size is not getting implemented in vhost , any specific reason ) 16:16
gibijust to double check16:16
gibiwe do not track anything for RC216:17
sean-k-mooneykeerthivasan86[m]: if i recall corectly its only supproted in vhost-user but not kernel vhost16:17
gibiis it corr4ect?16:17
sean-k-mooneygibi: not that im aware of16:18
keerthivasan86[m]sean-k-mooney: As part of vhost-net able to see rx_queue_size is implemented at vm level as well. It works for vhost-net as well 16:19
Ugglagibi, not yet. Do you think about FUP for vfio pci migration ?16:19
sean-k-mooneykeerthivasan86[m]: when it was implented there was a specific reaosn why we didnt enabled it16:19
gibiUggla: it is going to land on master probably today. I'm not advocating for pusing for an RC2 tomorrow just for that single thing. (it is not an Epoxy regression)16:20
sean-k-mooneykeerthivasan86[m]: that may haved chnted but the current code was becasue of how qemu/libivrt worked at the time we implemtned https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/libvirt-virtio-set-queue-sizes.html16:20
keerthivasan86[m]sean-k-mooney: if you are ok , can i work on to implement tx_queue_size for vhost-net ?16:21
sean-k-mooneysure but we need to know when it started to be supported, and we need to take accound of upgrades16:22
dansmiththe only PCI FUP that should be backported is doc stuff right?16:22
dansmithUggla: gibi ^16:22
dansmiththe test and cleanliness things should not be backported, IMHO, but definitely not hold up rc216:22
Ugglagibi, this is what I have in mind as well. Waiting for GA as this is the only thing.16:22
sean-k-mooneykeerthivasan86[m]: so im not sure fi it needs a spec or if a specless blueprint woudl be enough.16:22
sean-k-mooneydansmith: the doc is the one that really should be16:23
sean-k-mooneydansmith: some of the others are nice to have but not required16:23
dansmithbackporting test cleanliness doesn't make sense to me unless it's needed for an actual fix16:23
gibidansmith: for RC2 prespective only  https://review.opendev.org/c/openstack/nova/+/944105/5 in interesting16:23
sean-k-mooneyright the doc i could see for an RC2 but at this point i woudl just wait and do that after the release16:24
sean-k-mooneygibi: oh right to make numa work16:24
gibidansmith: but as I wrote above it is not an E regression and will only land today16:24
dansmithgibi: ah I missed that one.. that's not really a regression i t seems, but.. 16:24
dansmithack yeah okay16:24
gibiyeah I would not spin an RC2 just for thish16:25
gibibut if there are other things forcing an RC2 ...16:25
sean-k-mooneyso we can do a stable release basifcally right after the actual release16:25
dansmithright16:25
Uggla+116:25
sean-k-mooneyso i think  RC2 is overkill for any of those16:25
gibiyeah doing stable backports is the way to go if nothing else forces RC216:25
sean-k-mooneysounds like we are all in violent agreement16:25
gibiyepp16:26
bauzasyup16:26
bauzas(sorry, meeting was over)16:26
Ugglabauzas, no still in the meeting16:27
bauzasas a reminder, any new release candidate impacts our distros16:27
bauzasso we definitely only need to provide a RC2 if this is a regression16:27
elodilles(with my release core hat on) anyway, let me know if an RC2 is needed (or not needed) as this week is when we can release a final RC as i said o:)16:27
elodilles(i'll generate final RC patches (where there are merged and unreleased stuff on stable/2025.1) somewhere around 2nd half of the week fwiw)16:28
bauzasack thanks16:29
elodillesnp16:29
dansmithare we done?16:30
Ugglakeerthivasan86[m], are the answer of sean ok for you ?16:30
Ugglaany other topic ?16:31
masahitoquestion for the ptg topic selection and timeslot16:31
Ugglamasahito, the current topic are in the etherpad above.16:32
masahitothank. ah, yes. I added some.16:32
UgglaI think not all of them are available. I know new ones will come.16:33
UgglaThen we will organize the timeslot to discuss all of them.16:33
sean-k-mooneyUggla: i assume masahito wanted to ask about when there topics will be scheduled16:33
sean-k-mooneyor perhaps suggest when tehy are aviable16:33
masahitomy question is the ptg time slot is limited so i don't think the ptg can't cover all topics. so i want to know when and how it's decided.16:33
sean-k-mooneymasahito: we dont have many topics currently16:34
masahitos/ptg can't/ptg can/16:34
sean-k-mooneyi woudl be surrprised if we didnt cover them all16:34
UgglaI think for the time slot it will be almost ok next week.16:34
keerthivasan86[m]yes Uggla As sean-k-mooney suggested specless blueprint or fresh blueprint to implement tx_queue_size 16:35
opendevreviewsean mooney proposed openstack/placement master: improve test logging and replace psycopg2 with psycopg2-binary  https://review.opendev.org/c/openstack/placement/+/94548716:35
sean-k-mooneydansmith: ^16:35
keerthivasan86[m]can i create fresh blueprint to implement tx_queue_size for vhost-net feature ?16:35
dansmithsean-k-mooney: ack16:35
UgglaMasahito, we’ll try to accommodate your schedule so you can join.16:36
masahitoi got it for the next week meeting.16:36
Ugglaany other topic ?16:36
masahitothanks. I prefer 14:00UTC or later slot because of family reason as it's remote session :)16:36
Ugglamasahito, sure I'll keep that in mind.16:37
Ugglalooks we can close the meeting16:38
Ugglathanks all16:39
Uggla#endmeeting16:39
opendevmeetMeeting ended Tue Mar 25 16:39:27 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:39
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-25-16.00.html16:39
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-25-16.00.txt16:39
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-25-16.00.log.html16:39
elodillesthanks Uggla o/16:39
masahitothank you o/16:39
Ugglaelodilles, ty16:39
bauzasUggla: bravo for your first meeting :)16:42
Ugglabauzas, ty16:44
gibiUggla: thanks16:46
simondodsleyelodilles: not sure if you saw the conversation yesterday, but are the stable cores open to backport these 3 XS patches to resolve the SCSI page 83 passthrough issue: https://review.opendev.org/q/topic:%22lun-device-serial%2217:33
gboutryHello, I'm currently splitting my hair around https://bugs.launchpad.net/ubuntu/+source/nova/+bug/210341318:10
gboutryI'm currently running nova 31.0.0RC1 tag on python3.13, and I can't create a new instance.18:10
gboutryWhen I'm trying to, I'm getting the error described in the ticket.18:10
gboutryAt around nova/nova/network/neutron.py:1233 (allocate_for_instance), admin_client.httpclient.dict seems to get totally wiped18:10
gboutrygoing from  {'session': <keystoneauth1.session.Session object at 0x7e1a2c601950>,... 'endpoint_override': None, ...} to {} (empty dict)18:10
gboutryThus failing with the error in the lp bug. the line number it happens varies but always in the function, so this looks like a finalizer going off the rails?18:10
gboutryThis seems python 3.13 related, but I'm not sure18:10
gboutryI would appreciate any advice :)18:11
sean-k-mooneygboutry: 3.13 is not offically supproted yet18:13
sean-k-mooneyit might work but its not actully tested18:13
sean-k-mooneyhttps://github.com/openstack/governance/blob/master/reference/runtimes/2025.1.rst is the supproted python verisons18:13
sean-k-mooneygboutry: initall testing for 3.13 will be part of 2025.2 and it will only become requried in 2026.118:14
gboutrysean-k-mooney: thanks for the info, Epoxy is targeted to be released in Ubuntu Plucky (25.04) which is using Python 3.13, we'll most likely need to carry a patch downstream if I can find the root cause of this issue18:16
sean-k-mooneygboutry: i wonder if this could be eventlet related. teh error is coming form keystone authg via neutron client18:16
gboutryI am getting some eventlet assertion errors in the background: https://pastebin.ubuntu.com/p/WhKxDrvQHt/18:17
gboutryhttps://github.com/eventlet/eventlet/commit/4d48d10b990910cc87ec6bbeeaea63b295fe314d python 3.13 has been added in this commit18:18
gboutryI'll continue poking in this direction, thanks18:18
sean-k-mooneyso that after fork thing has come up before18:19
sean-k-mooneywe had to workaround a behvior change i think in 3.11 or 3.1218:19
sean-k-mooneyto make sure we got the right id18:19
sean-k-mooneyperhasp that broken on 3.13 again18:19
sean-k-mooneygboutry: https://github.com/eventlet/eventlet/issues/59218:22
sean-k-mooneywe remvoed that workaroudn in epoxy https://github.com/openstack/nova/commit/cd980cdd1ea957a9aa2220014046ea53079a623f18:22
sean-k-mooneybecause it has been fixed for a long time in eventlet18:23
sean-k-mooneygboutry: you could try reverting that again locally and see if it fixes that issue on 3.13 but its really a eventlet bug and a regression fo something they previosly fixed18:23
sean-k-mooneyhum well not quite18:24
gboutryThanks for the insight! I'll comeback later (need to take care of something), after reverting that, I'll report back!18:24
sean-k-mooneyits a slightly diffent error18:24
sean-k-mooneybtu realted to the same code18:24
sean-k-mooneycool18:24
gboutryyes, this happens in the new code specific for python 3.13 support haha18:25
sean-k-mooneygboutry: if you figure it out let us know. we will be trying to enable 3.13 this cycle and dont have issue with backproting non invaisive change to supprot it in 2025.1 but it wont officlaly be supproted for a while18:30
mikalsean-k-mooney: sorry I missed the meeting, I was asleep. I am not entirely sure I know what a "specless blueprint" is. Is that just a blueprint in launchpad? There is already one for the SPICE work, are you saying I need a second one for the extra specs stuff?19:01
sean-k-mooneymikal: a specless blueprint is just a launchpad blueprint that we agree does not require a spec so we approch based on the description of the bluepint in the irc meeting19:02
sean-k-mooneyi.e. if we belive it not contoverioal enough of big enough to need a spec19:02
sean-k-mooneythe current blueprint for the spice direct work will be closed as completed shortly19:03
sean-k-mooneywe should have a new blueprint for the vdi part fo 2025.219:03
mikalAhhh, ok.19:03
sean-k-mooneymikal: i dont know if folks will want a mini spec for the vdi part or be fine with a detailed blueprint19:03
sean-k-mooneygiven it basicaly code complete already and we discussed the design last cycle19:04
sean-k-mooneymikal: regarding sleep you can add the bleuprint to the team meeting wiki or just ask async on the mailing list for it to be dicussed at the next one19:05
sean-k-mooneymikal: i ment to bring it up today i just didnt have a link to the vdi work 19:06
mikalHuh. There are a surprisingly large number of SPICE blueprints on launchpad.19:07
sean-k-mooneyya and a couple of video/audio/vdi ones19:07
mikalYeah, this is news to me. I shall have to read them.19:07
sean-k-mooneylike https://blueprints.launchpad.net/nova/+spec/libvirt-audio-device19:08
sean-k-mooneymikal: I dont think any of them are relevnet anymore19:08
sean-k-mooneymikal: im ot aware of anyoen actully working on them19:08
mikalAnd https://blueprints.launchpad.net/nova/+spec/libvirt-spice-video-sound-driver19:08
sean-k-mooney ya that the really old one19:09
sean-k-mooneythere is also a usb redirection one19:09
mikalIt would be nice to just close all of these (either as addressed or not) as part of landing the VDI stuff.19:09
sean-k-mooneyhonestly its proably cleaner if you just file one for libvirt-vdi or similar that covers all yoru usecases19:09
sean-k-mooneyya19:10
sean-k-mooneyit would be good to clean them up19:10
mikalOh for sure, but I should _read_ the ancient ones too19:10
mikalThere might be wisdom of the ancients there or something.19:10
sean-k-mooneymaybe most look pretty empty but not all19:10
sean-k-mooneymikal: if nothing else it shows there si some interest form other to improve vdi on openstack19:13
mikalWell, there once was. Presumably 2015 guy has gone and done something else now.19:13
mikalI feel like https://blueprints.launchpad.net/nova/+spec/libvirt-spice-vdi is a bit sparse, but I am really not sure what else to put in it.19:13
sean-k-mooneyi would copy past some of the old spec that descibe the image properies/extra specs you plan to add19:14
sean-k-mooneymikal: by the way while your usecase is mainly spice the vdi enchnemnt wont sticrtly need spice at least for the audio devce19:16
sean-k-mooneynot that it will be very useful with vnc via the proxy19:17
mikalThat is true. I presume "direct VNC" would be possible if there was a suitable proxy and would use these features too, but that's forward looking.19:18
sean-k-mooneyya if you ever extend kerbside for that we could add it. i think you can get a better vnc conneciotn if you tunnel websocket back into a tcp connecton and use a better clinet but we dont ereally ahve anythignfor that out of the box19:19
mikalI have this underlying suspicion that I should be feasible to transcode between SPICE and RDP in Kerbside, and I think that might interest some people. However, the RDP specs are at least partially locked down in telco standards which cost money, and its not something I am likely to find the time for anytime soon.19:20
mikals/that I should be/that it should be/19:20
mikalI tweaked https://blueprints.launchpad.net/nova/+spec/libvirt-spice-vdi, but its not an essay.19:21
sean-k-mooneyya that looks ok.19:22
sean-k-mooneyso the process is bascilly see if peopel think its "simple enough to not need a spec" 19:22
sean-k-mooneyif the other cores say sure we apprve it for the cycle if not we will ask for a spec and just do that dance19:23
mikalOk. Should I send an email to the list, or is this conversation sufficient to get it onto an agenda somewhere?19:24
sean-k-mooneyideally you would add it to https://wiki.openstack.org/wiki/Meetings/Nova#Weekly_Nova_team_meeting in open dicssion  section19:25
sean-k-mooneyif you want to also add a link to the irc logs fo this converstaion that fine.19:25
sean-k-mooneyhttps://meetings.opendev.org/irclogs/%23openstack-nova/latest.log.html#t2025-03-25T19:01:2719:26
mikalDone.19:39
opendevreviewmitya-eremeev-2 proposed openstack/nova master: Add ability to preserve ephemeral in evacuation  https://review.opendev.org/c/openstack/nova/+/93823519:52
opendevreviewmitya-eremeev-2 proposed openstack/nova master: Handle ephemeral root disk in evacuation  https://review.opendev.org/c/openstack/nova/+/93823520:00
opendevreviewmelanie witt proposed openstack/nova stable/2025.1: unified limits: discover service ID and region ID  https://review.opendev.org/c/openstack/nova/+/94552520:37
gboutrysean-k-mooney: I've tried multiple things, including reverting that patch, without much success.20:56
gboutryI have a small reproducer, but not sure if it is relevant in nova context?20:56
gboutryhttps://pastebin.ubuntu.com/p/t8pDTvdNqB/20:56
gboutryOr even if it makes much sense, but it gets the same error, I'll dig in more tomorrow, thanks for your support!20:56
sean-k-mooneyso what i think is happening is when we monkeypatch thread its not properly replacing the tread id with the grenthread id20:57
sean-k-mooneywhich is what casueing the assert to fail20:57
sean-k-mooneyor somehting along those lines20:57
sean-k-mooneybut ya that seam like an eventlet bug not a nova one20:57

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