| *** mhen_ is now known as mhen | 02:49 | |
| opendevreview | Esra Ozkan proposed openstack/nova master: Fix Concurrent VM Live Migrate - Volume Backup Error https://review.opendev.org/c/openstack/nova/+/973750 | 07:04 |
|---|---|---|
| do3meli | hi, can someone please help to get workflows triggered for https://review.opendev.org/c/openstack/nova/+/972276 ? | 07:50 |
| stephenfin | gibi: o/ any chance you can look at https://review.opendev.org/c/openstack/nova/+/971460 again? I replied to your question | 08:01 |
| opendevreview | Merged openstack/nova-specs master: Create specs directory for 2026.2 Hibiscus https://review.opendev.org/c/openstack/nova-specs/+/973373 | 08:35 |
| gibi | stephenfin: done. And as I see we did it in parallel with bauzas :) so you are now double approved | 08:43 |
| bauzas | lol | 08:43 |
| bauzas | tkajinam: I'll look at gibi's comments today, you'll get a merge conflict on the top of your series due to the fact we just approved another unrelated patch fyi | 08:44 |
| gibi | bauzas: is the conflict due to the parallel refactor series? If so we can decide on the landing order to limit the number of conflicts | 08:50 |
| bauzas | gibi: I explained it in the top-level comment for 971460, my opinion is that we can quickly merge stephenfin's patch because tkajinam's series is still actively under review | 08:53 |
| bauzas | gibi: I just saw you made good comments on the firmware autodetection patches, mostly the one about the default XML setting we should or shouldn't set | 08:54 |
| gibi | ahh OK so it is not the mem encryption context refactor | 08:54 |
| bauzas | nope | 08:55 |
| gibi | cool then | 08:55 |
| gibi | stephenfin's patch is landing and that is just a single patch so no further decision needed | 08:55 |
| opendevreview | Johannes Beisiegel proposed openstack/nova master: Adds packing_host_pci_numa_cells_allocation_strategy option https://review.opendev.org/c/openstack/nova/+/952451 | 08:59 |
| opendevreview | Johannes Beisiegel proposed openstack/nova master: Adds packing_host_pci_numa_cells_allocation_strategy option https://review.opendev.org/c/openstack/nova/+/952451 | 09:01 |
| tkajinam | bauzas, no problem about rebase. I'll do it once that patch is merged | 09:11 |
| opendevreview | Merged openstack/nova stable/2025.2: libvirt: Skip unsupported firmware types https://review.opendev.org/c/openstack/nova/+/972276 | 10:17 |
| gibi | stephenfin: when you have a minute I updated https://review.opendev.org/c/openstack/nova/+/969936 | 10:54 |
| * stephenfin looks | 10:54 | |
| stephenfin | done | 10:55 |
| gibi | thanks | 10:56 |
| opendevreview | Merged openstack/nova master: libvirt: Remove import hacks https://review.opendev.org/c/openstack/nova/+/971460 | 11:12 |
| opendevreview | Merged openstack/nova master: mem-enc: create generic check for mem encryption support by host https://review.opendev.org/c/openstack/nova/+/967969 | 11:23 |
| *** sambork_ is now known as sambork | 12:34 | |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Extend functional test coverage of UEFI boot guests https://review.opendev.org/c/openstack/nova/+/969263 | 12:47 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add basic xml generation for firmware auto selection https://review.opendev.org/c/openstack/nova/+/969085 | 12:47 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load loader and nvram from xml https://review.opendev.org/c/openstack/nova/+/969086 | 12:47 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load ssm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131 | 12:47 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | 12:47 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Allow no progress field https://review.opendev.org/c/openstack/nova/+/973819 | 12:52 |
| opendevreview | Takashi Kajinami proposed openstack/nova stable/2025.1: libvirt: Skip unsupported firmware types https://review.opendev.org/c/openstack/nova/+/973821 | 12:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | 13:18 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware + compute eventlet removal patches https://review.opendev.org/c/openstack/nova/+/973468 | 13:19 |
| elodilles | hi nova-stable-maint members o/ can i get 2nd reviews/+W for this trivial CI fix patches? https://review.opendev.org/q/topic:fix-zuul-config-error-nova+branch:%5Estable/.* | 13:26 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949 | 13:27 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | 13:27 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware + compute eventlet removal patches https://review.opendev.org/c/openstack/nova/+/973468 | 13:27 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949 | 13:29 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | 13:29 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware + compute eventlet removal patches https://review.opendev.org/c/openstack/nova/+/973468 | 13:29 |
| gibi | bauzas: I found the issue of the failed volume detach, guest kernel crash, you noticed in my libvirt event patch | 13:50 |
| bauzas | gibi: ack, I was driving stephenfin to be back at the bus station for heading back to his house | 13:57 |
| gibi | bauzas: ohh cool :) | 13:59 |
| masahito | Hi nova team, please review this lock API bug fix https://review.opendev.org/c/openstack/nova/+/946223/5 . | 14:04 |
| opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Install pcre packages only in doc jobs https://review.opendev.org/c/openstack/python-novaclient/+/973846 | 15:15 |
| opendevreview | Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances https://review.opendev.org/c/openstack/nova/+/939254 | 15:15 |
| opendevreview | Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances https://review.opendev.org/c/openstack/nova/+/939254 | 15:18 |
| Uggla | Nova meeting in ~30mn | 15:23 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | 15:54 |
| tkajinam | Uggla, shall we start ? :-) | 16:02 |
| Uggla | #startmeeting nova | 16:02 |
| opendevmeet | Meeting started Mon Jan 19 16:02:33 2026 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:02 |
| opendevmeet | The meeting name has been set to 'nova' | 16:02 |
| nicolairuckel | o/ | 16:02 |
| gibi | o/ | 16:02 |
| Uggla | Hello everyone | 16:02 |
| tkajinam | o/ | 16:02 |
| elodilles | o/ | 16:02 |
| tkajinam | I was too impatient :-P | 16:03 |
| Uggla | Back from pto(conference) again. Not sure I have completely landed yet. ;) | 16:03 |
| Uggla | tkajinam, yep it seems. | 16:03 |
| bauzas | o/ | 16:04 |
| womax | o/ | 16:05 |
| Uggla | Let's start | 16:05 |
| Uggla | #topic Bugs (stuck/critical) | 16:05 |
| Uggla | #info No Critical bug | 16:05 |
| Uggla | #topic Gate status | 16: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-minimal | 16: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 status | 16: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 recheck | 16:06 |
| fwiesel | o/ | 16:06 |
| opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: DNM testing https://review.opendev.org/c/openstack/python-novaclient/+/973861 | 16:06 |
| Uggla | I haven't seen something special around the gates. Please tell me if I'm wrong. | 16:07 |
| Uggla | #topic Release Planning | 16:07 |
| Uggla | #link https://releases.openstack.org/gazpacho/schedule.html | 16:07 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:07 |
| Uggla | #info 6 weeks before feature freeze | 16:08 |
| Uggla | #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg | 16:08 |
| * Uggla slowly catching up with the status in launchpad and above doc/ | 16:08 | |
| Uggla | #topic Review priorities | 16:08 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2026.1-status | 16:08 |
| * Uggla slowly catching up with the status in launchpad and above doc | 16:08 | |
| Uggla | #topic OpenAPI | 16:09 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:09 |
| Uggla | #info still 19 remaining atm. | 16:09 |
| Uggla | #topic Stable Branches | 16:09 |
| * Uggla giving the mic to elodilles | 16:09 | |
| elodilles | thanks Uggla | 16:09 |
| elodilles | actually, nothing to report | 16:10 |
| elodilles | #info stable gates seem to be in good state | 16:10 |
| elodilles | that's all from me for now | 16:10 |
| Uggla | thx elodilles | 16:10 |
| elodilles | np | 16:10 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:11 |
| Uggla | fwiesel, anything to report from your side ? | 16:11 |
| fwiesel | No, nothing from my side. | 16:12 |
| fwiesel | Uggla: Back to you | 16:12 |
| gibi | fwiesel: one thing | 16:12 |
| gibi | would it be possible to run the vmware job with nova-compute switched to threaded mode and using this patch? https://review.opendev.org/c/openstack/nova/+/973468 | 16:12 |
| gibi | https://docs.openstack.org/nova/latest/admin/concurrency.html#selecting-concurrency-mode-for-a-service this gives you the hint how to configure nova-compute to run in threaded mode | 16:14 |
| fwiesel | Sure, should I activate the threaded mode by default? Or just one run? | 16:14 |
| gibi | you need to pull in the nova-compute patches from that series | 16:14 |
| gibi | and the oslo.vmware patches form the depends on | 16:15 |
| gibi | and set the env variable OS_NOVA_DISABLE_EVENTLET_PATCHING=true | 16:15 |
| gibi | for the nova-compute process | 16:15 |
| fwiesel | So one manual run for now... I can do that. | 16:15 |
| gibi | yepp just to see if the smokes comes out or nit | 16:16 |
| gibi | not | 16:16 |
| gibi | thank | 16:16 |
| gibi | s | 16:16 |
| fwiesel | You're welcome. | 16:16 |
| fwiesel | Uggla: Now back to you, I presume. | 16:17 |
| Uggla | thx | 16:17 |
| Uggla | #topic Gibi's news about eventlet removal | 16:17 |
| * Uggla giving the mic to gibi | 16:17 | |
| gibi | thanks | 16:17 |
| gibi | no big news | 16:17 |
| gibi | we made review progress in the nova-compute series | 16:18 |
| gibi | that is all for now | 16:18 |
| gibi | back to you | 16:18 |
| Uggla | thx gibi. | 16:20 |
| bauzas | we had back-to-back meetings but I saw your reply, I still wonder whether we're missing some libvirt event but fair | 16:20 |
| bauzas | I'll accept your patch but I'll continue to monitor the jobs | 16:21 |
| Uggla | #topic Open discussion | 16:21 |
| Uggla | We have one topic from womax | 16:21 |
| Uggla | (womax) Potential future use of tempURL in nova | 16:21 |
| womax` | yes | 16:22 |
| Uggla | womax` the floor is yours | 16:22 |
| womax` | so for context, I recently worked in ironic to add support for multi store and s3 image stored. Ironic is using temp URL as way to download image on baremetal machine | 16:22 |
| womax` | the work lead me to write code very similar on what is present in glance, and so I'm currently trying to propose moving the handling of tempURL in glance. But glance is not so keen on having features in glance that would only be used in ironic | 16:23 |
| womax` | While working on temp URL we also saw a way to avoid glance being a bottleneck while downloading image, and so I wanted to ask opinions, on wether such a feature would exist, is it something that would be accepted to be used also in nova | 16:24 |
| womax` | Idea would be in nova rather than downloading image directly from glance it would ask glance for a tempURL and then download the image from there (so directly from the storage backend) | 16:25 |
| fwiesel | Funny thing, the vmware driver (in nova and cinder) could profit from it. We implemented in our fork that we generate a tempURL, because then the vcenter can download the image directly instead the having to pipe it through the nova-compute agent. | 16:28 |
| Uggla | womax` I don't have strong opinion on that, because I don't know well that part. Clearly I would like to know what dansmith thinks about it. | 16:29 |
| nicolairuckel | I have a topic for open discussion too (of course after that). | 16:29 |
| tkajinam | sounds sensible to me | 16:29 |
| gibi | what is the benefit of the direct download? | 16:29 |
| tkajinam | gibi, IIUC it does not require proxy by glance | 16:30 |
| fwiesel | gibi: Saving one hop | 16:30 |
| tkajinam | in case glance uses swift backend currently when nova downloads an image from glance the data goes in swift -> glance -> nova | 16:30 |
| gibi | OK so the use case here is better performance. | 16:30 |
| tkajinam | but the proposal removes glance from the path | 16:30 |
| fwiesel | Ah, and no token based authentication. | 16:30 |
| gibi | any drawback? | 16:30 |
| womax` | better performance for downloads but also avoiding glance being overloaded | 16:31 |
| gibi | doea glance provide aome service we lose if we not go through it? | 16:31 |
| womax` | gibi: from glance side, a token revocation would have take time to propagate, as tempURL have no to being revokated, but ttl is in order of minutes | 16:31 |
| womax` | aome? | 16:32 |
| gibi | sorry 'some' | 16:32 |
| womax` | glance provide caching to avoid hitting too much the storage backend, temp URL would that, but it would be configurable and up to operators to see what is better for them | 16:33 |
| womax` | other than that I don't think we would lose anything | 16:33 |
| womax` | tempURL would bypass caching* | 16:34 |
| gibi | OK. Based on these I feel like it make sense to draw up a spec to get quorum, but looks good to me so far | 16:34 |
| womax` | spec in nova I assume? | 16:34 |
| fwiesel | Well, another issue is reliability. tempUrls are shortlived by design, and if the tempURL expires during your download you cannot retry (by design). Openstack authentication is stronger, and has retry methods | 16:34 |
| gibi | womax yepp spec in nova and in glance | 16:35 |
| womax` | in glance it already drafted and they are currently waiting for nova opinions before going further | 16:35 |
| gibi | i assume it impacts both | 16:35 |
| gibi | cool | 16:35 |
| womax` | I can also do it for nova to have more opinions | 16:35 |
| tkajinam | fwiesel, yeah. we have service user token but it may not work for tempurl . | 16:36 |
| gibi | yes please, and link the glance spec | 16:36 |
| gibi | fwiesel: good point, lets include that to the spec to solve | 16:36 |
| womax` | gibi: ok | 16:36 |
| tkajinam | we probably need know better about the interaction between nova and glance so that we won't leak anything problematic | 16:37 |
| tkajinam | especially in case a image is a shared one | 16:37 |
| tkajinam | (We can discuss details in the spec) | 16:37 |
| gibi | ++ | 16:37 |
| fwiesel | swift_store_multi_tenant=True is another edge case | 16:38 |
| womax` | ok, i'll start drafting and come back when it is ready, to discuss more in details | 16:38 |
| tkajinam | sounds nice :-) | 16:38 |
| Uggla | Are we ok with that topic ? womax` ? | 16:40 |
| womax` | Uggla: yes | 16:41 |
| Uggla | ok so nicolairuckel, please go ahead with your topic | 16:41 |
| nicolairuckel | I was wondering if it makes sense to move the discussion about how to deal with secure boot and resetting the NVRAM (https://review.opendev.org/c/openstack/nova/+/959682?tab=comments) from my patch to another place. This is relevant for cold migration which we excluded from my patch. The discussion is of course important for my (hopefully) next patch but I'm not sure where to put that/how to deal with that. | 16:41 |
| nicolairuckel | Unless it is a blocker for my current patch of course. Last week it sounded like we need to discuss that beforehand but after reading the comments I'm not so sure anymore. | 16:41 |
| Uggla | nicolairuckel my understanding, your patch just need a small addendum: prohibiting migration with os_secure_boot='optional' is an option. per haps its a suffience one for the short term | 16:47 |
| nicolairuckel | I thought that's only an issue for cold migration. | 16:47 |
| tkajinam | no it also affects bare hard reboot and hard reboot after live migration. | 16:48 |
| * tkajinam is adding a comment | 16:48 | |
| nicolairuckel | Ah, somehow I missed that. | 16:49 |
| nicolairuckel | Thank you. | 16:49 |
| nicolairuckel | I'll work on that then. | 16:49 |
| tkajinam | I think the point is that it's difficult to fix these all. I think we need an agreement about what we accept while fixing an annoying reset behavior | 16:49 |
| Uggla | I don't think so, it seems something sean-k-mooney would like to have for this patch and then another one with a long term solution. | 16:49 |
| nicolairuckel | But then it makes sense to have the discussion there and we don't really need to discuss that here. | 16:50 |
| sean-k-mooney | oh o/ | 16:50 |
| sean-k-mooney | reading back | 16:50 |
| nicolairuckel | i just missed that there's actually something else I need to do before the review can continue. | 16:51 |
| sean-k-mooney | Uggla: honestly i think the os_secure_boot=optional stuff is out of scope | 16:51 |
| sean-k-mooney | for the initall reboot patch | 16:51 |
| sean-k-mooney | that was just ment to fix preserving the nvram file for hard reboot nothing more or less | 16:51 |
| Uggla | ok | 16:52 |
| nicolairuckel | Then my original point still stands that the discussion should be at another place, right? So we can merge the patch but don't lose the discussion in the process. I mean, it would still be there but kind of the wrong place. | 16:52 |
| nicolairuckel | I'm just not sure how to proceed at the moment. | 16:52 |
| sean-k-mooney | hard reboot in my opion shoudl nto change the secure boot state of the vm. that ideally woudl be fixed when the vm was first booted and stay the ame for its lifetime or only change on a resize or rebuild | 16:56 |
| sean-k-mooney | im aware that not what happens today but i woudl prefer not to expand the nvram bug with fixing that | 16:56 |
| sean-k-mooney | idealaly we woudl deal with os_secure_boot=optional as its own bug what ever way we decied to proceed with that | 16:57 |
| tkajinam | sounds reasonable to me | 16:59 |
| Uggla | nicolairuckel is that clarify your thoughts ? | 17:00 |
| nicolairuckel | I think so. Then we create a new bug and leave the patch as is? | 17:01 |
| nicolairuckel | Unless something comes up during the review of course. | 17:01 |
| Uggla | yep that's my understanding. | 17:01 |
| sean-k-mooney | that works for me but lets actully file the bug before proceedign with the patch | 17:01 |
| Uggla | yep so we can relate to it | 17:02 |
| sean-k-mooney | if we want to chat about that second bug we can do so briefly after teh meetign wraps | 17:02 |
| nicolairuckel | sounds good to me. Who will file the bug? | 17:02 |
| Uggla | nicolairuckel, if you are confortable to do it, that would be great. | 17:02 |
| Uggla | Ok we are at the to of the hour. So I guess we can close that meeting. | 17:04 |
| Uggla | Thanks for joining this meeting. Have a nice day/evening and see you next week. | 17:05 |
| Uggla | #endmeeting | 17:05 |
| opendevmeet | Meeting ended Mon Jan 19 17:05:21 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:05 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.html | 17:05 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.txt | 17:05 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.log.html | 17:05 |
| gibi | thanks | 17:05 |
| Uggla | no time for bug triage... I guess I need to find another way to address that topic. | 17:06 |
| tkajinam | One thing I'd add about CI. Python 3.13 job was moved from Ubuntu Noble to Debian Trixie. it may cause some problems in python 3.13 jobs | 17:06 |
| tkajinam | so far I'm aware that py313 job in python-novaclient is broken and https://review.opendev.org/c/openstack/python-novaclient/+/973846 fixes it | 17:06 |
| Uggla | tkajinam, thanks for the info ! | 17:06 |
| tkajinam | (the migration was done only in master. py313 job in stable branches still runs in Noble) | 17:07 |
| tkajinam | so it's better to keep eyes on py313 jobs for a while | 17:07 |
| tkajinam | I mean openstack-tox-py313 and any jobs inheriting it | 17:07 |
| nicolairuckel | I think it would make sense if tkajinam files the bug as he knows more about it but of course I can also write something and then update it with feedback from tkajinam and sean-k-mooney. I'm fine either way. | 17:08 |
| sean-k-mooney | i think that woudl only cause issues if we had bindep problems like how we define pcre as a dep | 17:08 |
| tkajinam | sean-k-mooney, yup | 17:08 |
| sean-k-mooney | i could be wrong about that but it is good to keep an eye on the py313 job in any case | 17:08 |
| sean-k-mooney | so for the secure boot optional case i have 2 tought on it | 17:09 |
| sean-k-mooney | as i noted above i think the fact we dont fix the behavior on first boot is arguabel a but but that does not mean there is not merit in the current behavior | 17:09 |
| sean-k-mooney | my concern with it ever changign after the workload is created is basiclly it can break the geust os if it does | 17:10 |
| sean-k-mooney | my other tought on this is dan mention that the ver all interaction is starting to get complex enough that perhaps we need a spec to defien the behvior longterm | 17:10 |
| sean-k-mooney | the guiding principal for nova is alwasy "what woudl the behvior be if this was a physical system" | 17:11 |
| sean-k-mooney | on a phsyical system rebooting host or movign it form one rack to another woudl nto change the bios config or the nvram | 17:11 |
| tkajinam | nicolairuckel, I can create one later this week | 17:11 |
| sean-k-mooney | however if you were reinstallign the OS you might do that | 17:12 |
| sean-k-mooney | and if you are cahngign the hardware you might do that too. so rebuild and resize coudl be valid point to change the secure boot config in my view | 17:12 |
| sean-k-mooney | hard reboot or cold/live migrate dont fit with the "what woudl happen with a real server" lithmus test if the secure boot or nvram sate chagnes | 17:13 |
| nicolairuckel | thank you, tkajinam. Let me know if I can help/contribute. | 17:13 |
| sean-k-mooney | tkajinam: nicolairuckel that the critia im trying to apply if that makes sense. | 17:13 |
| nicolairuckel | yes, that makes sense to me | 17:14 |
| tkajinam | sean-k-mooney, cold migration is most problematic. because it basically inherits resize which assumes that the instance can be rebuilt... | 17:15 |
| sean-k-mooney | tkajinam: in the short term we could provide a workaround flag to block cold/live migration with os_secure_boot=optional or we could record the current state somewhere say in instnace_system_netadata and ensure it does not change when we do migrate | 17:15 |
| sean-k-mooney | tkajinam: ya, the other wrinkel is we can preserve the nvram if its there but unfrotuanlly that is not enough to tell us if we need to enable secure boot or not in the xml | 17:16 |
| tkajinam | makes sense | 17:16 |
| sean-k-mooney | that why we need to stash the state somewhere in the cold migrate and shelve/unshelve case | 17:17 |
| sean-k-mooney | shelve/unshelve today loses the nvram so it will regenerate it regardless today | 17:17 |
| tkajinam | another scenario I still have to consider in additiona to os_firmware_secure='optional' is the case where a different firmware is selected after hard reboot but I'll give more thoughts to it. | 17:18 |
| sean-k-mooney | but again preserving it is out of scope fo the iniall reboot bug | 17:18 |
| tkajinam | an annoying thing is that it's not clear how these firmware files are updated (due to no documentation about their update policy) | 17:18 |
| sean-k-mooney | right the frimware itself and the base tempelates are part of the ovmf package i bleive | 17:19 |
| tkajinam | yeah | 17:19 |
| sean-k-mooney | so they update when the host package is updated | 17:19 |
| sean-k-mooney | tkajinam: when we use the statelest firmware feature do we still have an nvram file? i think no correct? | 17:20 |
| tkajinam | sean-k-mooney, no | 17:20 |
| tkajinam | yeah so one example question which I can't answer now is "can existing code file and var file be updated when ovmf package is updated ? then do we need to reset nvram in that case ?" | 17:20 |
| sean-k-mooney | its unfortunet that windows stores it bitlocker keys or key config in the nvram file | 17:21 |
| tkajinam | I totally agree | 17:21 |
| sean-k-mooney | the update of the ovmf package just updates teh template | 17:21 |
| sean-k-mooney | but i guess nova woudl have update the backign file because the existng nvram was lost on hard-reboot | 17:21 |
| sean-k-mooney | so in parctis it woudl have updated after the next vm reboot after the host package but i dont think that is what shoudl have been expected | 17:22 |
| tkajinam | I hope so but compatibility between template and var is quite unclear, tbvh | 17:23 |
| sean-k-mooney | ya im not really sure how the qemu/libvirt/ovmf comuity expect that too work | 17:24 |
| sean-k-mooney | if they provided a migraton tool to migrate the nvram file to a newer version invoking that woudl be a potinally reasonabel thing to do on hard reboot | 17:24 |
| sean-k-mooney | but im not aware of any such tool | 17:25 |
| sean-k-mooney | it might exsit i have never looked into it | 17:25 |
| sean-k-mooney | ai says no that tool does not exsit for what that worth | 17:28 |
| nicolairuckel | Is there other software that uses qemu, libvirt, or ovmf that may have the same problem? | 17:29 |
| nicolairuckel | Then it might make sense to see how other projects handle that issue. | 17:30 |
| sean-k-mooney | yes, kubvirt, proxmox and virtuozo but apprently the fix is delete the file losing the data and just recreate it in the rare case it does nto work | 17:30 |
| sean-k-mooney | apprently imcompatiablity is rare | 17:30 |
| nicolairuckel | That doesn't sound like a very elegant solution though. | 17:30 |
| sean-k-mooney | its not but unintally that has been what nova did by defualt becuase we were alwsy regenerating it | 17:31 |
| nicolairuckel | I see... | 17:35 |
| sean-k-mooney | nova uefi supprot predates secure boot support and bitlocker using the nvram var to sotre its config so that behavior as not initally observed or problematic | 17:36 |
| sean-k-mooney | i.e. we were not aware that libvirt was deletign the nvram when we underfiend the domain. | 17:38 |
| tkajinam | quick search shows kubevirt supports persistence of uefi vars (which by default does not persist uefi vars) but no useful information about its lifecycle management really :-( | 17:42 |
| tkajinam | https://kubevirt.io/user-guide/compute/persistent_tpm_and_uefi_state/ | 17:42 |
| tkajinam | if anyone from the core have a moment to review/merge https://review.opendev.org/c/openstack/python-novaclient/+/973846 to fix py313 job, that'd be nice. | 17:44 |
| * tkajinam runs away | 17:44 | |
| sean-k-mooney | tkajinam: i belive that a releivitly new fetature and it currently has some limeiations | 17:55 |
| sean-k-mooney | tkajinam: there are some internal difcusion with the virt folks about the correct way that and vtpm should sork i bleive and htey havnt really figuried it all out yet | 17:56 |
| tkajinam | hmm | 17:56 |
| sean-k-mooney | i dont really know the details jsu tnoteice it was on the virt devel list which might be upstream actully not sure | 17:56 |
| sean-k-mooney | there was some discussion about live migration and the use of pvcs to store the nvram/tpm data | 17:57 |
| sean-k-mooney | im ont aware of anythign related to "how do we mighate teh data if ovmf updates" | 17:57 |
| tkajinam | ok | 17:57 |
| tkajinam | I'll see if any public outcome can be found | 17:58 |
| tkajinam | sean-k-mooney, thanks for that info ! | 17:58 |
| sean-k-mooney | what im tryign to avoid is the need to have a glance iamge property or flavor extra spec for persictence other then the ephermal firmware flag | 17:59 |
| sean-k-mooney | basiclaly if you want ephermal firmware i think you shoudl opt into it | 17:59 |
| sean-k-mooney | otherwise we shoudl treat the tpm and nvram data as user data and persitit it | 18:00 |
| sean-k-mooney | i have no idea where we woudl eventually store it for shleve but that a future us problem | 18:00 |
| sean-k-mooney | orginally i was hopign the tpm and nvram files would be small enough to be able to store as secrete in barbican in teh future | 18:02 |
| sean-k-mooney | but that was just an idea not something i looked into | 18:02 |
| sean-k-mooney | the nvram and tpm data is privlaged enouch that i woudl not be comfrotable storign it in glance unless it was encypted | 18:03 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!