Tuesday, 2025-10-14

*** mhen_ is now known as mhen01:53
LarsErikP"07:25
sean-k-mooneyLarsErikP: "08:11
sean-k-mooney:)08:11
LarsErikPsean-k-mooney: fat-finger-tuesday? :P08:11
sean-k-mooneycant just leave un closed quots by them selves they coudl get lonely08:12
opendevreviewSylvain Bauza proposed openstack/nova master: Fix fill_metadata usage for the ImagePropertiesWeigher  https://review.opendev.org/c/openstack/nova/+/96335808:12
LarsErikPfair point :P08:12
bauzassean-k-mooney: thanks for the help on autopep8, I'll look at the alt keys indeed before committing08:12
sean-k-mooneybauzas: i reallised it worse for you08:12
sean-k-mooneyso you have a artzy keyboard right08:13
sean-k-mooneyso your # us ib 308:13
sean-k-mooney*is on 08:13
bauzasmaybe because I'm using a french kb, yes08:13
bauzasyeah, Alt-Gr + 308:13
sean-k-mooneyya so you press altgr 3 to type hash08:13
bauzascorrect08:13
bauzasbut I had no issues before AFAICR08:13
sean-k-mooneyha so for me and  its just the key above shift and for the use i think its shift 308:14
bauzaslemme write some code and cat the file08:14
bauzasmaybe that's a VSCode/Codium issue08:14
sean-k-mooneyno its a local kmap issue 08:14
bauzasI was having the same issue with Codium and not only Cursor08:14
sean-k-mooneyonce i relicated it i coudl do it in emacs as well08:15
sean-k-mooneyprobably other editor too08:15
sean-k-mooneyoh well they may have other key binds that intercept it 08:15
sean-k-mooneyi can only  do it with altgr because left alt is bound ot other things in vscode08:15
sean-k-mooneyoh no for me alt space is grabbed by kde08:17
sean-k-mooneyits the applicaton laucher08:17
bauzasjust created a new file08:17
bauzashttps://paste.opendev.org/show/btgI58rkgJvf4i6XkWcO/08:18
bauzasI wasn't seeing any keys when catting 08:18
bauzasbut lemme check the chars08:18
sean-k-mooneydo cat -vet  nova/poc_wip.py 08:19
sean-k-mooneyand you wil see the unicode08:19
bauzasinteresting https://paste.opendev.org/show/bd91pr4uhj1SrmkHRjry/08:21
sean-k-mooneyya so M-BM-08:22
sean-k-mooneyis what a non breaking space looks like08:22
bauzaslemme try with vim to write another file08:22
sean-k-mooneythere are plugins by the way for vscode to remove "irrgualar spaces" 08:23
sean-k-mooneythis is apprently a common enough thing that people took the time to write one08:23
sean-k-mooneyi didnt want to recomend any specific one sicne i have never tested them or veted them08:23
sean-k-mooney"Fix Irregular Whitespace" is the most downloaded one08:25
bauzascan also reproduce it with vim08:25
opendevreviewTaketani Ryo proposed openstack/nova-specs master: Adjust the SEV/SEV-ES code for multiple cc support  https://review.opendev.org/c/openstack/nova-specs/+/96257808:25
bauzasso that's not an editor issue, definitely a keyboard mapping problem08:26
bauzasoh fuck I found why08:27
bauzasthat's PEBKAC08:27
bauzasI'm typing too fast so I wasn't releasing the altgr key when hitting space08:28
bauzasso I was typing 'hashtag' (altgr-3) then 'alternative-mapping' (alt-gr space)08:28
bauzasdoh, I should set altgr-space to write a space 08:29
opendevreviewBogdan Dobrelya proposed openstack/nova master: Determine the device type from configuration first  https://review.opendev.org/c/openstack/nova/+/96370208:33
sean-k-mooneybauzas: ya that is what i was assuming and because you have # on altgr 3 unlike the rest of us where it etiehr does not hava  modifyier or its shift 308:37
sean-k-mooneyyou are just more likely ot pres altgr space then the rest of us08:37
bauzasyeah, I tested : shift-space produces a space, while altgr-space produces a non-visible combination of "M-BM- + space"08:40
* gibi intrigued by bauzas' keyboard mapping08:59
bauzaschecked Gnome and my mapping is French (alt.) : confirmed that it hits nobreakspace09:02
bauzasthat probably changed in a fedora upgrade09:02
bauzaschanged my mapping to French, now it should be fixed09:09
bauzasthanks all09:09
opendevreviewBogdan Dobrelya proposed openstack/nova master: Determine the device type from configuration first  https://review.opendev.org/c/openstack/nova/+/96370209:42
tkajinamhmm it seems functional tests in osc-placement is failing due to a warning log added to placement recently https://bugs.launchpad.net/placement/+bug/212784811:23
tkajinamgibi, I wonder if that log should be really a warning or can it be debug ? https://opendev.org/openstack/placement/blame/commit/af09d65c3e24f214c43aebcb9cd069703ee87050/placement/objects/allocation_candidate.py#L82711:24
tkajinam(by the way we should use warning instead of warn...11:35
opendevreviewTakashi Kajinami proposed openstack/placement master: Replace LOG.warn  https://review.opendev.org/c/openstack/placement/+/96394811:35
sean-k-mooneytkajinam: it depend on if its actionable or not11:45
sean-k-mooneyit proably shoudl be info level11:46
sean-k-mooneywith that said osc-placemetn shoudl not be asserting anyting related to placmenet logging11:47
sean-k-mooneyso this feels more like a osc placement bug in the test setup11:47
sean-k-mooneythe placemetn logs form the placemetn fixture shoudl be capsture in the est setup and filtered out of that assertion11:48
sean-k-mooneyin a real envonment that log woudl not be aviabel to the client11:49
sean-k-mooneytkajinam: so the proper fix woudl be to install a log filter int eh osc-palcement functional tests i think to null route the placement logs11:50
tkajinamsean-k-mooney, yeah I agree the issue and the lo level should be separate...11:56
tkajinamsean-k-mooney, I looked into the logging setting but it looks tricky to me. the core problem is that the test does not use actual nova api but uses placement api fixture and filtering all placement logs mean we lost all api logs https://opendev.org/openstack/osc-placement/src/branch/master/osc_placement/tests/functional/base.py#L7711:57
tkajinamthe test does not use actual *placement* api, I mean11:57
tkajinammaybe we could raise it to ERROR ?11:57
sean-k-mooneytkajinam: correct we shoudl nto have access to any of the api logs in osc-placement12:00
sean-k-mooneyosc-placmenet is the openstack client plugin and in real code it will only have access to the api respocne not hte logs12:01
tkajinamit may be correct for assertions but I'm a bit afraid of loosing debuggability in test failures12:01
sean-k-mooneyso if any test is relying on the logs then that test is invlaid12:01
sean-k-mooneywe can keep the logs for the fixture but we shoudl not be loging the placment logs to stdout or stderr in generall but we shoudl atttach teh logs to the test output12:02
sean-k-mooneywe can proably do somethign like this https://github.com/openstack/nova/blob/master/nova/config.py#L56-L8912:05
sean-k-mooneyadd a log filt to the root loger that will intercept and redirect the logging else where but ill admit i have not tired12:05
tkajinamok12:05
tkajinamlet me give it some tries but I might just end up with bumping the log level filter to error12:06
sean-k-mooneyperhaps like this https://github.com/openstack/nova/blob/8b81b5f91ffe1f9c38a483d151b82316d443dbf6/nova/tests/fixtures/nova.py#L190-L19912:07
sean-k-mooneywe may be able ot patch where placmenet or the placment fixutrer setup up logging iwth our own funciton12:08
sean-k-mooneytkajinam: i assume this is repoducable if we just clone master and run the tests?12:08
tkajinamyup12:09
tkajinamreplace openstack-placement>=1.0.0 in tox.ini by git+https://opendev.org/openstack/placement#egg=openstack-placement12:09
tkajinamso that it uses non-released version12:09
tkajinam(that's what you need after clone, before tox -e functional12:09
sean-k-mooneyack. ill see if i can play around with it locally too12:09
sean-k-mooneytanks for reporting this12:09
sean-k-mooneyim on pto the rest of the week and i dont have too much time today so i cant promis ill make much progress but i have a littel time between meeting today12:10
gibitkajinam: that log will disappeare once we land a fix https://review.opendev.org/c/openstack/placement/+/962776 . I (wrongly) assumed that we will land the two patches close together so did not worried about the extra logs in the reproduce commit12:11
sean-k-mooneygibi: well it found a bug as a result but that also a good pont it shoudl be resovle when the actual fix lands12:13
gibiit was a log I added to prove that root cause of the bug12:14
gibiit is not necessary in production12:15
gibiI can spin up a patch that removes it independently from https://review.opendev.org/c/openstack/placement/+/96277612:15
gibiso we can restore the sanity of the osc-placement's gate12:15
* gibi goes spinning12:15
gibiI did not load context on why osc-placement test depends on placmenet api logs. But that can be (and probably should be) fixed separately from unblocking the gate12:17
tkajinamgibi, ah, thanks !12:19
opendevreviewBalazs Gibizer proposed openstack/placement master: Remove troubleshooting logs  https://review.opendev.org/c/openstack/placement/+/96395212:22
gibisean-k-mooney: , tkajinam ^^12:23
opendevreviewTakashi Kajinami proposed openstack/osc-placement master: Filter out placement api logs in functional tests  https://review.opendev.org/c/openstack/osc-placement/+/96395312:23
tkajinam^^^ sean-k-mooney gibi: this is the initial try to filter out these logs in osc-placement functional tests12:24
tkajinamgibi, thanks !12:24
gibitkajinam: I'm OK with that. If CI is green then I think we can land your test setup fix12:25
gibithat will probably land faster than my placement log removal patch 12:26
sean-k-mooneytkajinam: i think that is fine we could proably be more granular but im not oppose to that12:26
tkajinamyeah we could probable filter more specific module but I tend to try with that wider filtering and see if that kills out life12:27
tkajinam* our life12:27
tkajinammy concern with narrow filtering is that we may face similar problems frequently in the future12:27
tkajinamso far it worked in my local reproducer but let's see how CI passes...12:28
sean-k-mooneyso what i was going to propsoe is lsightly diffent. i was going to try and capture the placment api logs into a seperate stringio buffer and make them aviabel in tests but only log them if you run the test in debug mode12:28
sean-k-mooneyso similar to how https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/capture.py works internally12:30
sean-k-mooneyor rather similar ot how https://github.com/openstack/oslotest/blob/9c1cb8e6df468a459783b49d59c60eee3cf83d4d/oslotest/log.py#L35 works internaly12:31
sean-k-mooneycurrently the way our test are setup teh python loing module is set up to log to stdout and stderr12:33
sean-k-mooneythen https://github.com/openstack/oslotest/blob/9c1cb8e6df468a459783b49d59c60eee3cf83d4d/oslotest/output.py#L64-L7112:33
sean-k-mooneyintercept that if we enabel that fixture12:33
sean-k-mooneyso what i want to try and do is see if i can redirect the placement loggers to a stringstream or stringio buffer instead and add them to the base test class as self.placment_api_log12:35
sean-k-mooneytkajinam: gibi  just to be clear im fine with proceexcing with tkajinam's patch if it passes ci12:35
gibicool. I think tkajinam's fix can land fast to unblock the gate12:36
gibithere is at least on green functional run already in 96395312:37
gibiI mean in https://zuul.opendev.org/t/openstack/status?change=96395312:37
tkajinamsean-k-mooney, I didn't try that way first, because in these functional tests of osc-placement we have a single root logger which receives both placement log and osc-placmenet's log12:41
tkajinamwe can technically add different handlers and select these according to log module name but that's what current fixtures in oslotest and placement are designed for12:41
tkajinam(I'm not saying we can't/shouldn't do it but I'm saying we need additional consideration for this specific use case12:42
sean-k-mooneyya. lets not rush to make that work but if we can split it cleanly later it coudl be nice12:42
sean-k-mooneyi am +2w on your current patch so if ci is green it will merge12:42
gibisean-k-mooney: thanks12:43
gibiit passed check and on the gate now. So I'm abandoning https://review.opendev.org/c/openstack/placement/+/96395212:49
opendevreviewMerged openstack/osc-placement master: Filter out placement api logs in functional tests  https://review.opendev.org/c/openstack/osc-placement/+/96395312:52
opendevreviewTakashi Kajinami proposed openstack/osc-placement master: Replace remaining py39 target  https://review.opendev.org/c/openstack/osc-placement/+/96380912:53
tkajinam\o/12:54
*** haleyb|out is now known as haleyb12:59
gibithat was a quick one. Thanks folks13:01
sean-k-mooneygibi: i got ai to implement the other approch as well im just cleaning it up and makeing sure work properly13:06
* bauzas reading back, gibi sean-k-mooney anything I can help to review ?13:13
sean-k-mooneybauzas: no we are good we merged the quick fix to resolve the gate issue13:17
ratailorsean-k-mooney, gibi bauzas could you please review https://review.opendev.org/c/openstack/nova/+/937534 https://review.opendev.org/c/openstack/nova/+/938054 and https://review.opendev.org/c/openstack/nova/+/93429413:19
bauzassean-k-mooney: cool sorry I wasn't looking at the channel13:25
opendevreviewsean mooney proposed openstack/osc-placement master: Improve functional test debuggability with log capture  https://review.opendev.org/c/openstack/osc-placement/+/96396213:30
sean-k-mooneygibi: tkajinam  i need to join a call but  ^ shoudl work13:30
sean-k-mooney...13:30
sean-k-mooneyafter i fix the whitespace issues13:30
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277613:40
gibisean-k-mooney: dansmith: ^^ fixed up based on Dan's comments13:40
dansmithbauzas: if you're looking for reviews, we're still hoping you can +W the bottom two patches in the vtpm series13:44
dansmithand of course, contribute to the reviews up the stack13:44
bauzasshit, my brain forgor :)13:44
bauzasforgot* 13:44
dansmithbauzas: https://review.opendev.org/c/openstack/nova/+/961734/413:45
opendevreviewsean mooney proposed openstack/osc-placement master: Improve functional test debuggability with log capture  https://review.opendev.org/c/openstack/osc-placement/+/96396214:17
UgglaNova meeting in ~30mn15:28
opendevreviewMerged openstack/nova master: Add functional reproducer for bug 2125030  https://review.opendev.org/c/openstack/nova/+/96173415:30
*** gmaan_pto is now known as gmaan16:00
Uggla#startmeeting nova16:01
opendevmeetMeeting started Tue Oct 14 16:01:59 2025 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.16:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:01
opendevmeetThe meeting name has been set to 'nova'16:01
gibio/16:02
bauzaso/16:02
nicolairuckelo/16:02
gmaano/16:02
opendevreviewTakashi Natsume proposed openstack/nova master: Update contributor guide for 2026.1 Gazpacho  https://review.opendev.org/c/openstack/nova/+/96189616:02
* gibi is on a parallel meeting 16:02
fwieselo/16:02
Ugglahey gmaan welcome back ;)16:03
gibigmaan: oooh hi!16:04
sean-k-mooneyo/16:04
gmaanhi16:04
UgglaLet's start slowly.16:05
elodilleso/16:05
Uggla#topic Bugs (stuck/critical) 16:05
Uggla#info No Critical bug16:05
Uggla#topic Gate status16:05
Uggla#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16: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 a meaningful comment when you recheck16:06
Ugglashame on me I have not looked at the gate.16:06
UgglaHave you seen something bad with it ?16:07
bauzasI saw some failures but the ones I was knowing16:08
sean-k-mooneybauzas: volume issue and kernel panics?16:08
bauzasssh timeout at least16:09
gibiI saw guest ssh timeouts in couple of times in different test cases but did not dig deep16:09
sean-k-mooneyack16:09
bauzaseg. https://zuul.opendev.org/t/openstack/build/83dac09bed7947dead180357cb14d35716:09
gibiohh we have matching observation16:09
sean-k-mooneythat ocationaly happens but if its increaseing we may need to debug16:09
bauzaswe'll see with my rechecks :)16:10
sean-k-mooneygibi: was the issue with some vms geting multipel port fixed do you know?16:10
sean-k-mooneyim not saying that related but just wondering if you new16:11
gibiI don't recall the issue 16:11
sean-k-mooney*knew16:11
sean-k-mooneyack no worries16:11
gibianyhow or the guest ssh I will keep an eye on it16:11
sean-k-mooneyone of the provider was allcoating mulitple port to nodpoolvms which sometimes broke the network connectivy on the computes16:11
sean-k-mooneyi assume that has been fixed16:11
sean-k-mooneyit wasnt a nova problem16:11
gibiohh now I recall it. I haven't see that appearing recently16:11
sean-k-mooneyack16:11
sean-k-mooneythat job only has one port as expected so as i said not related16:12
sean-k-mooneywe can proably move on unless anyone else has somethign16:13
gibijepp, lets move on16:14
UgglaI agree16:14
UgglaSkipping next point, as I want gmaan to come back smoothly.16:14
Uggla#topic Release Planning 16:14
Uggla#link https://releases.openstack.org/gazpacho/schedule.html16:14
Uggla#info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg16:14
Uggla#info Please add the topics you would like to discuss in the above document.16:15
Uggla#info PTG meetings (to be confirmed) will happen room grizzly 15:00UTC -> 17:00UTC from Tuesday to Friday16:15
UgglaNote, I'm currently crafting the PTG etherpad defining the timeslots.16:16
gibiUggla: 15-16, 16-17, or also 17-18?16:16
gibiI mean the last starting time is 17UTC or the finish time is 17 UTC?16:16
sean-k-mooneyyep ^ its an inclusive range of startimes16:16
sean-k-mooneyso its really 15:00-18:0016:16
Ugglayep 15:00 --> 18:00 CET16:17
gibiack, so 3 hours for 4 days16:17
gibiworks forme16:17
sean-k-mooneybased on https://ptg.opendev.org/ptg.html16:17
Ugglayep as usual, starting (Tue)16:17
sean-k-mooneywell you need to adjust that actully16:17
sean-k-mooneyit curernly show all 5 hours not just the fine 3 in the slot16:18
Ugglasean-k-mooney yes I reserved a bit larger at the first shot16:20
bauzasat least the slots are booked16:21
Ugglayep :)16:21
bauzasif we need to continue to discuss, we can book another slot... or we can unbook another one :)16:21
UgglaI'will arrange that in the coming days16:22
Ugglaok moving on16:24
Uggla#topic OpenAPI 16:25
Uggla#link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned16:25
Uggla#info still 28 remaining atm.16:25
Uggla#topic Stable Branches 16:25
* Uggla giving the voice to elodilles16:25
elodillesthanks o/16:26
elodilles#info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state16:26
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:26
elodilles#info 2024.1 Caracal (stable/2024.1) moves to Unmaintained at the end of next week - final stable Caracal release should be proposed and merged ASAP16:26
elodilles#info elod will propose the release patches tomorrow16:26
elodillesand a question:16:27
elodillesdoes anyone have any important patch to land to stable/2024.1 before we release? (list of open patches: https://etherpad.opendev.org/p/nova-stable-caracal-eom )16:27
Uggla-16:27
gibi-16:27
elodillesthanks for the reviews so far, btw!16:27
elodillesUggla: gibi: ACK, then i'll propose the review patches right away (flamingo, epoxy, dalmatian, caracal)16:28
elodilles(though caracal is the most important for now o:))16:28
elodillesand that's all from me about stable for now16:29
gibipoor caracal, I will miss it16:29
elodilles:]16:29
Ugglarip caracal16:29
elodillesyou don't have to dig it, it won't go to EOL, just Unmaintained o:)16:29
elodillesso people can still backport bug fixes to unmaintained/2024.1 ;)16:29
sean-k-mooneyelodilles: as an aside there is only ment to be one unmtianed slurp release at a time16:30
gibiyeah basicaly kicked out to the streets nice elodilles :)16:30
sean-k-mooneyelodilles: im fine with not enforce that as long as you still care about the rest16:30
elodillessean-k-mooney: in case there is no volunteer to keep open unmaintained/2023.116:30
sean-k-mooneybut in thory 2023.1 is ment to go eol when 2024.1 moves to unmainted16:30
gmaanantelope is still unmaintained, any plan to move to EOL before caracal moving to unmaintained ?16:31
gmaansean-k-mooney: yeah16:31
sean-k-mooneyso i think elodilles  is still interested in keeping it alive16:31
gmaanbecause based on that we need to see if we can continue running grenade job on unmaintained caracal16:31
sean-k-mooneyso as long as the gates are green that is fine16:31
sean-k-mooneywell grenade is not ment to test upgrades form unmaintained16:32
gmaanas long as it run green then no harm to test it but if previous base relaese is not maintained or broken then yes we can remove16:32
elodillessean-k-mooney: yes, i want to step up as a volunteer to keep it open16:32
sean-k-mooneyor rahter the oldest stable is not ment to test upgrading form unmaintaiend but you coudl run it your self i guess16:33
elodillessean-k-mooney: yes, the oldest stable is officially not supported, so can be disabled, though if it works then i'd rather ask for keeping it, and also help maintaining it as long as it possible16:34
sean-k-mooneywell the counter point to that16:35
sean-k-mooneyis we want to evntually be able to remove old disto images and mirrors16:35
sean-k-mooneyso im not objecting to keepign it for a release or two bvut we shoudl nto keep it indefinetly16:36
elodillesof course if it blocks the gate then it can be removed (though i'd rather set it as non-voting if not completely unfixable or broken forever)16:36
elodillessean-k-mooney: +116:36
sean-k-mooney2023.1 is using ubuntu 22.04 which is supprot until 202716:36
sean-k-mooneythat kind of the upper bound on testing that IMO16:36
sean-k-mooneyso it has 18months+ runway i think16:37
sean-k-mooneyanyway we can likely move on since its not being EOLd this cycle but we could talk about it more at the ptg if poepel wanted16:37
elodillesyepp16:38
gmaanI am only concern about the running grenade skip job on Epoxy which will be from caracal to Epoxy and if we can continue running it it will be great16:39
gmaanand it seems like we will do that until it is broken so I am good here16:39
elodillesgmaan: ++16:39
Ugglaok so moving on.16:40
Ugglathx elodilles16:40
Uggla#topic vmwareapi 3rd-party CI efforts Highlights16:40
fwiesel No updates from my side16:40
Ugglafwiesel thanks16:41
Uggla#topic Gibi's news about eventlet removal16:41
gibio/16:41
Ugglagibi anything on your side ?16:41
gibithen first couple of patches are reviewable on https://review.opendev.org/c/openstack/nova/+/956089/16:42
gibiand the ptg etherpad as the longer term plan16:42
gibiAlso please report any strange test failures from nova-next, since last week we run conduct there in threading mode as well16:42
gibi(top of scheduler api, and metadata)16:43
gibithat is ti16:43
gibiit16:43
sean-k-mooneyhum on the rbd thread pool i guess everually we will wnat to use the asinc api instead16:43
sean-k-mooneyso we can actully pass timeouts ectra16:43
sean-k-mooneybut i guess the intial plan is to just not swapn it on a tread pool at  all which i guess is ok16:44
gibisean-k-mooney: this will not prevent doing that later when we actaully go and translate the nova-compute16:44
sean-k-mooneyack ya just chekcign that still the medium term plan16:44
gibithe patches on that series are for unblocking unit testing16:44
opendevreviewMerged openstack/nova master: Move cleanup of vTPM secret from driver to compute  https://review.opendev.org/c/openstack/nova/+/96200716:44
sean-k-mooneyah ok16:45
gibiI think we can move on16:47
Ugglathx gibi16:47
Uggla#topic Open discussion 16:47
UgglaJust a reminder for the poll:  Pool for the new schedule of upstream meeting: https://framadate.org/ao12zK6wR3K3nfbF16:47
UgglaAnything you want to discuss ?16:48
nicolairuckelI worked on a patch to preserve the NVRAM after reboots that got mentioned a few weeks ago.16:48
nicolairuckelI'm not sure if that's the correct place to talk about that.16:48
Ugglayes16:48
nicolairuckelhttps://review.opendev.org/c/openstack/nova/+/95968216:48
sean-k-mooneylooks like it needs a rebase16:49
nicolairuckelThe only caveat is that at the moment you have to set the permissions for the NVRAM file manually. I wasn't able to figure out if there's a way to change the permissions through libvirt.16:49
nicolairuckelsean-k-mooney, I'll do that!16:50
sean-k-mooneywhy do you need to do that?16:50
nicolairuckelIf you don't add read permissions, there will be a permissions error on a reboot and it won't be preserved.16:51
nicolairuckelThe libvirt people told me that the permissions are like than intentionally. It's just a bit weird to me that the disk file has read permissions.16:52
sean-k-mooneywait why are you copying the file to the instnce dir an back16:52
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/959682/3/nova/virt/libvirt/driver.py#1091916:52
nicolairuckelThe file contains the UEFI variables that I want to preserve.16:52
sean-k-mooneyi tought we were goign to preseve this by passign the libvirt flag to the doamin cleanup to preserve the file16:52
nicolairuckelYou mean I could skip copying the file?16:53
sean-k-mooneyyes 16:53
nicolairuckelI see. I'm going to try that.16:53
sean-k-mooneyso for the vtpm data we can pass a flag to tell libvirt not to delete it when the domein is undefiend16:53
sean-k-mooneyi belive we can do the same for the nvram16:54
sean-k-mooneyi could be mistaken but i belive there was a flag for the nvram as well16:54
nicolairuckelThat would be a better solution for sure.16:54
sean-k-mooneyso we would not need ot copy the file16:54
nicolairuckelI'm going to look into that, thank you.16:54
nicolairuckelHow can I find a reviewer when that is done? Should I just bring it up again next week?16:55
sean-k-mooneyyou can also ping on irc 16:56
nicolairuckelokay16:56
sean-k-mooneywe will proably see it updated but you can reach out if we dont16:57
Ugglanicolairuckel, ping on the channel16:57
nicolairuckelthanks16:57
nicolairuckelthat would be all from my side then16:57
gibinicolairuckel: thanks for working on it16:57
sean-k-mooneyVIR_DOMAIN_UNDEFINE_KEEP_NVRAM16:58
sean-k-mooneyhttps://github.com/libvirt/libvirt/blob/b42a12174c787b99cd6fcb29b44e4b13bd64ee58/include/libvirt/libvirt-domain.h#L237316:58
sean-k-mooneythat the flag we need to pass to not delete it when the domain is undeifed16:58
Ugglanicolairuckel, yes thanks for working on it16:58
Ugglatime to close17:00
UgglaThank you for participating in this meeting.17:00
Uggla#endmeeting17:00
opendevmeetMeeting ended Tue Oct 14 17:00:39 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-14-16.01.html17:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-14-16.01.txt17:00
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-14-16.01.log.html17:00
elodillesthanks o/17:01
gibihanks17:03
gibithanks17:03
gibi:)17:03
elodillestom? o:)17:06
gibinemtom (sorry this only funny in hungarian)17:10
sean-k-mooneyby the way im on pto retruning on tusday17:18
sean-k-mooneyjust an fyi that i wont be here for the rest of the week17:18
gibisean-k-mooney: have a nice one17:19
opendevreviewMerged openstack/nova master: Switch nova-conductor to use global executor  https://review.opendev.org/c/openstack/nova/+/96247818:45
opendevreviewHenry Richter proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565720:09
opendevreviewFernando Ferraz proposed openstack/nova master: [DNM] Get processutils logs from unprivileged_convert_image  https://review.opendev.org/c/openstack/nova/+/96409522:01
opendevreviewmelanie witt proposed openstack/nova master: Add handling for vTPM secret permission error  https://review.opendev.org/c/openstack/nova/+/96364823:22

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