| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-05 | |||
| 16:11:07 | Uggla | #info Nova deadlines are set in the above schedule | |
| 16:12:15 | Uggla | Time is flying, a bit less than 4 weeks before FF. | |
| 16:12:26 | Uggla | #topic Review priorities | |
| 16:12:36 | Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | |
| 16:13:12 | Uggla | I guess the file is updated, please let me know if something is wrong in it. | |
| 16:13:29 | Uggla | #topic OpenAPI | |
| 16:13:37 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:13:59 | Uggla | #info up from 13 to 32 remaining. (I guess Stephen created new ones and follow up) | |
| 16:14:24 | Uggla | I hope we can see an end about this. | |
| 16:15:01 | Uggla | I'm going to skip stable branch topic because Elod is on pto. | |
| 16:15:28 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:15:36 | Uggla | fwiesel, something on our side ? | |
| 16:15:44 | fwiesel | #info fwiesel will be on PTO until the 9/9 | |
| 16:15:54 | fwiesel | Otherwise, no news from me. | |
| 16:16:07 | fwiesel | Uggla: back to you | |
| 16:16:23 | Uggla | fwiesel, I wish you'll enjoy your PTO. | |
| 16:16:33 | fwiesel | Thanks! | |
| 16:17:25 | Uggla | Also skiping Gibi's point about eventlet removal due to Gibi's well deserved pto. | |
| 16:17:59 | Uggla | #topic Open discussion | |
| 16:18:17 | melwitt | I have a small topic | |
| 16:18:18 | Uggla | So jssfr, giving the mic to you. | |
| 16:18:26 | jssfr | thanks! | |
| 16:18:38 | jssfr | so we're currently looking into two topics which are somewhat related: | |
| 16:18:41 | jssfr | first we're rebasing https://review.opendev.org/c/openstack/nova/+/621646 | |
| 16:18:53 | jssfr | second I proposed a draft patch for a vTPM data preservation issue a couple weeks ago: https://review.opendev.org/c/openstack/nova/+/955657 | |
| 16:19:22 | sean-k-mooney | o/ sorry was doign something else | |
| 16:19:26 | jssfr | o/ | |
| 16:19:38 | jssfr | I also think that sean-k-mooney proposed something similar to the vTPM draft for UEFI NVRAM preservation | |
| 16:20:00 | jssfr | we'd like to hear whether we're heading the right direction by rebasing #621646 regarding UEFI, or whether there might be a better way. | |
| 16:20:17 | sean-k-mooney | i was suggeing bring it up in this meetign yes | |
| 16:20:20 | melwitt | oh, good. this was the topic I wanted heh (vTPM data) | |
| 16:20:24 | sean-k-mooney | or rather that melwitt bring it up | |
| 16:20:35 | jssfr | I also saw only now that you replied to #955657, because I had my inbox sorting messed up, reading that now. | |
| 16:21:00 | sean-k-mooney | melwitt: do you want to summerize | |
| 16:21:08 | jssfr | read it | |
| 16:21:12 | melwitt | sure | |
| 16:21:33 | melwitt | we are looking for input and consensus about handling the recently raised issue in the community regarding vTPM data that is lost across guest reboots https://bugs.launchpad.net/nova/+bug/2118888 and https://review.opendev.org/c/openstack/nova/+/955657 the tl;dr is that this is a latent problem that originates in libvirt | |
| 16:22:08 | melwitt | libvirt added a flag for this VIR_DOMAIN_UNDEFINE_KEEP_TPM a couple of years after vTPM was added in Nova and jssfr has proposed a patch for using the flag ^ | |
| 16:22:20 | jssfr | (which will need a bit of work, such as adding tests) | |
| 16:22:30 | jssfr | (but I can do that) | |
| 16:22:53 | sean-k-mooney | there is a related but seperate issue that related to the nvram data | |
| 16:23:08 | sean-k-mooney | again there are now flag to supprot keeping or removing the nvram file | |
| 16:23:32 | jssfr | (UEFI NVRAM bug is https://bugs.launchpad.net/nova/+bug/1785123, patch-with-merge-conflicts is https://review.opendev.org/c/openstack/nova/+/621646 ) | |
| 16:23:37 | dansmith | so if we do that, we need to do our own deleting of the TPM file when we undefine to actually delete the instance? | |
| 16:23:51 | jssfr | dansmith, no, because we can just not pass that flag when we truly want to delete | |
| 16:23:57 | sean-k-mooney | dansmith: no. we can pass the keep or delte flag as approtiate | |
| 16:23:58 | jssfr | in my draft patch, I tied it to the delete_storage bool IIRC | |
| 16:24:01 | dansmith | oh it's a flag _to_ undefine? | |
| 16:24:04 | jssfr | yes :) | |
| 16:24:06 | melwitt | yes | |
| 16:24:07 | dansmith | okay | |
| 16:24:26 | dansmith | ah I see yes, okay | |
| 16:24:57 | sean-k-mooney | so we have a number of placess we undefine the vm today wher the data shoudl not be deleted, hard-reboot is one but also some volume operations require use to temporlly undefien the domain | |
| 16:25:47 | melwitt | we are thinking about, how to fix this for older versions. the flag addition could be technically seen as a "feature" but IMHO the impact is quite significant and personally I would think about backporting the flag fix to older versions that could be reasonably expected to use libvirt >= 8.9.0 where the flag was introduced | |
| 16:26:13 | melwitt | wondering what others think of this | |
| 16:26:37 | jssfr | I think a backport would be quite appropriate | |
| 16:26:37 | dansmith | shifting behaviors in a library that we have to account for is not a feature, IMHO | |
| 16:26:44 | jssfr | and we are going to backport to at least 2024.1 anyway | |
| 16:27:15 | jssfr | so we could contribute those backported patches at least. | |
| 16:27:27 | sean-k-mooney | dansmith: the wrinkel is libvirt uncondtionally delete the data when we added vtpm supprot and the option to preseve it was added 2 years later | |
| 16:27:44 | dansmith | yeah understand | |
| 16:28:04 | sean-k-mooney | with that said the didnt really document that which is partly why we missed it but i agre we shoudl not require a feature to "do the write thign" | |
| 16:28:05 | jssfr | sean-k-mooney, so you're saying it's not shifting behaviour in libvirt, but simply a bug which existed since forever but which nobody noticed? | |
| 16:28:30 | sean-k-mooney | jssfr: yes, however that does not mean i belive we shoudl consider it a feature | |
| 16:28:51 | sean-k-mooney | i supprot the idea of fixing this condtional on the libvirt verison | |
| 16:28:54 | dansmith | it's shifting behavior and our failure to account for it is a bug not a feature | |
| 16:28:55 | jssfr | (I get the impression that "feature" versus "bug" is an important distinction here, but I'm not sure why. backporting/support policies?) | |
| 16:29:05 | sean-k-mooney | and possibel backporting that based on dicusssion with teh stable team | |
| 16:29:20 | melwitt | I agree with dansmith | |
| 16:29:41 | sean-k-mooney | dansmith: well the default never changed in libvirt. it still deleted on undefine by defualt. they just added the ablity to keep it in later release | |
| 16:29:56 | sean-k-mooney | so do we agree to treat this a logic bug in nova | |
| 16:30:03 | sean-k-mooney | i.e. that we didnt account for how this actully works | |
| 16:30:24 | sean-k-mooney | and if so are we ok with usign the flags to adress that | |
| 16:30:58 | sean-k-mooney | jssfr: yes the stable plociy does not allow feature backports upstream | |
| 16:31:05 | jssfr | aha, thanks! | |
| 16:31:11 | sean-k-mooney | jssfr: there are very limited excptions to that | |
| 16:31:52 | jssfr | noted, thanks. | |
| 16:32:25 | melwitt | I support backporting use of the flags (with libvirt version conditional) | |
| 16:32:40 | sean-k-mooney | im +1 on treating it as a but and fixing it by approatbly passing the flags to undefine based on if we are deleting the instance or just undefining for some other reason | |
| 16:33:31 | NicolaiRuckel | this applies to both vTPM and UEFI, right? | |
| 16:33:33 | sean-k-mooney | s/as a but/as a bug/ | |
| 16:33:49 | sean-k-mooney | so its the same patther and the same logic bug | |
| 16:34:07 | sean-k-mooney | so i think we could apply the same direction to both | |
| 16:34:34 | melwitt | +1 | |
| 16:34:39 | sean-k-mooney | the specific libvirt verions may differ for the relevent flags | |
| 16:34:39 | jssfr | sean-k-mooney, does this only apply for the accidental deletion on undefine for UEFI, or also for the loss of NVRAM data during migrations? | |
| 16:34:46 | sean-k-mooney | so we shoudl fix both as seperate patches | |
| 16:35:17 | sean-k-mooney | jssfr: nvram data is actully copied during live migration i belive | |
| 16:35:38 | sean-k-mooney | cold migration is sperate. we shoudl focus on the non move operations cases first | |
| 16:36:00 | jssfr | NicolaiRuckel, any evidence of nvram preservation during live migrations when initially rebased https://review.opendev.org/c/openstack/nova/+/621646 ? | |
| 16:36:15 | sean-k-mooney | im not sure which subset of opertions loose nvram data but fixing all fo them is not going to be a singel bug | |
| 16:36:27 | jssfr | understood, thanks. | |
| 16:36:31 | sean-k-mooney | jssfr: i belive its copied by qemu | |
| 16:36:51 | jssfr | aha | |
| 16:37:13 | jssfr | NicolaiRuckel, we'll have to double-check that in the devstack, without the rebased patches. | |
| 16:37:23 | NicolaiRuckel | yeah, I didn't try it yet | |
| 16:37:41 | NicolaiRuckel | There were so many failing test cases that I wanted to clean that up first. | |
| 16:38:02 | sean-k-mooney | i would sugget fixign one bug first then the other | |
| 16:38:18 | sean-k-mooney | i dont really have a prefence in order but proably vtpm might be less work | |
| 16:38:49 | sean-k-mooney | for nvram there is existing tech debt that need to be unwornd related to rebuild | |