Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-29
20:11:03 tbabel maybe we need another glance policy or something along those lines
20:11:24 melwitt that makes sense actually. image binary content is the property of the cloud but users can still make VMs
20:11:54 melwitt I guess if they made a VM with that image then they have the content anyway? I dunno
20:12:11 melwitt either way good for PTG discussion I think :)
20:12:26 gmaan yeah or snapshot VM or other hack:)
20:12:34 clarkb melwitt: yes it seems liek you could just dd the data off of disk
20:12:52 melwitt yeah
20:13:25 tbabel great question tbh, i'd have to prod the folks on my side further about the desire to block the download
20:28:02 gmaan melwitt: tbabel: anyways I added this topic in PTG etherpad under nova glance cross sessions - https://etherpad.opendev.org/p/nova-2026.1-ptg#L133
20:28:04 gmaan Uggla: ^^
20:28:21 gmaan feel free to update/add if something i missed
20:29:12 melwitt thanks gmaan
21:59:26 opendevreview melanie witt proposed openstack/nova-specs master: Re-propose vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/961564
22:44:57 opendevreview melanie witt proposed openstack/nova-specs master: Re-propose vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/961564
#openstack-nova - 2025-10-30
07:44:16 jkulik nicolairuckel: I understood from the discussion yesterday that it's fine that the permissions change - they should just change back to the originals i.e. back to being owned by nova once the VM isn't running anymore. that's not reflected in the ticket. did I misunderstand that part?
07:46:38 jkulik nicolairuckel: iirc, we also talked about it working like that ^ for disks. so having things behave differently would be something libvirt should consider and thus should be mentioned in the ticket, too, imho
08:05:26 nicolairuckel ah, right. I'll update the ticket.
09:05:00 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
09:33:48 opendevreview Nisha Brahmankar proposed openstack/nova-specs master: Add nova compute graceful shutdown spec https://review.opendev.org/c/openstack/nova-specs/+/965355
09:37:34 opendevreview Nisha Brahmankar proposed openstack/nova-specs master: Add nova compute graceful shutdown spec https://review.opendev.org/c/openstack/nova-specs/+/965355
09:47:02 nisha04 Thanks Uggla for the session schedule with a friendly timeslot :) I will see some of you at 00:00 UTC. Meanwhile please do check the spec if you get a chance!
09:49:55 Uggla Hi nisha04, happy that works for you !
10:06:31 Uggla bauzas, gibi if you have a chance to look at the above spec from nisha04 ^
10:35:38 bauzas Uggla: nisha04: no promises, we have a packed agenda and a limited time, I'll *try*
10:38:28 Uggla nisha04, also some of your colleagues wanted to bring metadata protection topic. But this was not submitted. Do you still want a slot about it ?
11:41:34 gibi Uggla: ack
11:47:15 opendevreview Takashi Kajinami proposed openstack/nova master: DNM: Let libvirt to select the correct UEFI firmware file https://review.opendev.org/c/openstack/nova/+/965366
11:53:10 gibi I left my initial feedback on the graceful shutdown spec
12:02:34 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
13:00:22 Uggla gibi thanks
13:46:13 Uggla Info: PTG Confidential computing related topics in around 15mn.
13:55:57 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
15:42:18 tkajinam does anyone remember when we discussed image formatter thing ?
15:42:42 tkajinam I remember we discussed direct kernel boot at that time and I'm trying to find out the discussion log ...
15:49:41 dansmith tkajinam: you mean when we discussed deprecating that stuff?
15:49:59 dansmith I looked it up and we technically only deprecated AMI and related formats not direct kernel boot
15:50:28 dansmith I can't remember but ... is direct kernel boot necessary for the confidential computing stuff?
15:50:29 tkajinam yeah
15:50:30 tkajinam https://review.opendev.org/c/openstack/nova/+/926144
15:50:38 tkajinam I found the same in git log
15:50:51 tkajinam dansmith, yeah. that's the first option to measure kernel and ramdisk at this moment
15:51:14 tkajinam there are some works to provide "trusted TPM" to do that measurement but that has been still in-progress for long
15:51:44 tkajinam direct kernel boot is used so that kernel binary, initramfs binary and OVMF code are passed down to CPU directly without any intermediate layers
15:52:30 tkajinam (and kernel command line)
15:52:31 tkajinam in that way CPU can measure these binaries and we can guarantee integrity of boot chain
15:53:14 tkajinam TPM and secure boot is used for similar manner but in confidential computing use case it's quite tricky to make sure integrity and trustness of TPM
15:53:29 tkajinam swtpm can't be trusted. It should run within the domain with encrypted data
15:53:53 dansmith ack, I think that the kernel/ramdisk support is still really gross and confusing, especially in a world where glance enforces the formats of things you upload to it,
15:54:07 tkajinam yeah
15:54:14 tkajinam I probably have to check if it still works first
15:54:15 dansmith but my main complaint is the AMI/ARI/AKI stuff itself, which nova has a bunch of garbage around
15:54:28 tkajinam yeah I remember we talked about that point
15:54:51 dansmith I tend to lump those formats together with AKI but as noted on that reno, they're not really the same thing and you can use direct kernel boot with other formats
15:54:56 tkajinam at that time what we wanted to deprecate ASAP was these AXI things while DKB can be independent
15:55:03 dansmith yes
15:56:21 tkajinam I'll watch the status of "trusted TPM" work in case we can just use it when I start SNP support work but my current guess is that it may take a few more years and we have to start with direct kernel boot
15:56:58 tkajinam (assuming the work needs another kernel/qemu/libvirt changes)
15:59:43 tkajinam ratailor, is that finish time thing is to fix the port detach/attach timing problem we discussed some time ago in heat ?
16:00:08 tkajinam I remember we need that mechanism to ensure that a port is fully released during port detach process
16:01:42 ratailor tkajinam, not fully remember this, but it was initially came as a bug here https://bugs.launchpad.net/nova/+bug/2058928 and then became feature because we need to add microversion to add finish_time field.
16:02:36 tkajinam ok. maybe I should ask that question to sean-k-mooney
16:03:54 ratailor tkajinam, if you are talking about ``Duplicate entry 'MAC/UUID-0' for key 'uniq_virtual_interfaces0address0deleted'`` then its related to that only.
16:06:11 tkajinam ah, ok and yes.that's one
16:11:36 sean-k-mooney tkajinam: o/
16:11:48 tkajinam sean-k-mooney, hey :-)
16:11:49 sean-k-mooney we just wrapped up the watcher session did you have a question
16:12:30 tkajinam sean-k-mooney, I was wondering if adding finish_time to instance action API is to fix the port detach problem during heat stack update we discussed some time ago
16:12:39 tkajinam I could not find the link for the bug/patch for some reason
16:13:10 sean-k-mooney tkajinam: yes it is
16:13:15 tkajinam ok
16:13:19 sean-k-mooney tkajinam: we discusse the workaround
16:13:27 sean-k-mooney which is heat can pool server show
16:13:33 tkajinam yeah
16:13:35 tkajinam I should probably look into updating heat to use that API though the tricky part is that heat is using novaclient at this moment :-P
16:13:41 sean-k-mooney but the correct fix is to actully mark the action as completed
16:13:44 tkajinam anyway that's one heat
16:13:44 tkajinam yeah
16:13:54 tkajinam that's "on" heat
16:18:48 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
17:13:10 tkajinam I'm dropping off. I might skip the sessions tomorrow.
17:13:44 gibi tkajinam: thanks for the contribution
17:13:51 tkajinam gibi, :-)
17:22:51 auniyal Uggla, any ideas if there will be time today for cyborg discussion from Sean ?
17:23:51 Uggla auniyal, yes probably. But I think the session will exceed 18:00UTC (sorry about that).
17:25:47 auniyal okay
17:40:30 dansmith Uggla: you're off mute
17:41:00 Uggla dansmith, sorry thanks notifying me.
17:41:41 dansmith Uggla: when you don't speak but are off mute, your AGC goes way high and we can hear everything in the background and even dust particles landing on your mic :)
17:42:51 Uggla dansmith, as bauzas said already, it is a diabolic plan for introducing French in the session. ;)
17:43:04 dansmith I will complain to the UN
17:44:08 Uggla dansmith, Usually I take care to mute, but as the day progressing I tend to forget. Yes I'm becoming old. ;)
17:46:09 gibi chrome has enable-webrtc-allow-input-volume-adjustment flag. But I don't have my wife home today to try it with the violin :)
#openstack-nova - 2025-10-31
09:13:33 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
09:27:33 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
10:39:16 opendevreview Balazs Gibizer proposed openstack/nova master: Do not fork compute workers in native threading mode https://review.opendev.org/c/openstack/nova/+/965466
10:39:17 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467
10:40:07 gibi sean-k-mooney: dansmith: sambork: ^^ I had first light with nova-compute in threading mode. I was able to boot and delete VMs in a local devstack. Let see how this fails on the gate with more complex operations
10:42:27 sean-k-mooney gibi: cool
10:42:54 sambork gibi, nice! change looks less impressive than I think it would :)
10:43:00 sean-k-mooney gibi: i have not looked yet but did you just make spawn a noop

Earlier   Later