| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-29 | |||
| 19:45:33 | gmaan | tbabel: melwitt yeah, you are right, it is always using auth from context (not the nova service user) https://github.com/openstack/nova/blob/30bf8c1025ea24823ebde3eacede4ea34ec6be8c/nova/image/glance.py#L66 | |
| 19:47:05 | tbabel | drats! Thanks for helping confirm! | |
| 19:50:13 | nicolairuckel | As we discussed earlier, I opened a bug report on libvirt for the NVRAM permissions: https://gitlab.com/libvirt/libvirt/-/issues/828 | |
| 19:50:39 | gmaan | we do it for other service like neutron and cinder but not for glance. I think we missed it. | |
| 19:51:23 | gmaan | I am adding it a quick topic in PTG if we get time to discuss it. to know if any specific reason not to do that or it is just missed. | |
| 19:52:43 | gmaan | and glance needs to make GET image for service role also. Currently glance does not allow it for service role | |
| 19:54:01 | tbabel | gmaan: Thank you! | |
| 19:56:42 | melwitt | gmaan: I think the initial GET should be the calling user though, user has to have permission to use the image right. but when it reaches nova-compute and a download is needed, I could see that being the nova service user | |
| 19:59:36 | gmaan | melwitt: yeah, true. even for GET image proxy API also we must continue to use the user token. but for nova-compute call we should pass some flag like 'privileged_user' and in that case we call glance with configured glance service user | |
| 20:00:13 | melwitt | gmaan: yeah makes sense | |
| 20:04:09 | gmaan | One thing I am not sure about and maybe good to discuss in PTG, that if that can be an issue where a user can still create instances from an image which is not allowed for them. But that is already a case for already cached images (on first instance or pre-cache mechanism) on that compute node. | |
| 20:07:59 | melwitt | gmaan: yeah, that's the thing. have to define what permission does a user need to create an instance. is GET enough (this happens in nova-api already)? or should they have download permission? | |
| 20:08:46 | tbabel | there's a couple cases there I think, even for the initial GET. In our case we allow all to get_image but don't want them to download_image. So the initial GET check will allow them to use it because it's a public image they can view/choose/select. | |
| 20:09:27 | melwitt | yeah. I was thinking if let's say nova didn't exist, a user would have to have download permission to be able to create a VM with that image | |
| 20:09:43 | melwitt | so I dunno | |
| 20:09:46 | gmaan | 'but don't want them to download_image.' you mean even cache in compute right? even that is internal compute workflow | |
| 20:10:25 | gmaan | yeah, it seems tricky if service user should dowload it for them | |
| 20:10:27 | tbabel | we want them to be able to use/build a vm with it, but not download them image locally or save it in any way outside of the system in general | |
| 20:10:39 | melwitt | ah, ok | |
| 20:10:41 | gmaan | i see | |
| 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 | yeah | |
| 16:13:44 | tkajinam | anyway that's one heat | |
| 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. | |