| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-29 | |||
| 19:16:01 | melwitt | tbabel: I think it would be the user's credentials (the one creating a new instance) | |
| 19:18:30 | tbabel | That's what it seems like but searches looking for more info are giving conflicting results. I have been able to verify that when the user is given a different role the download can happen and saved to a base image on the compute node. But wanted to see if this was something we can configure and force it to only use the nova service user to do such operations. | |
| 19:20:00 | melwitt | tbabel: yeah as far as I know there is no special treatment for fetching a base image ... nova does the same thing either way and if the image isn't cached yet, it caches it after it downloads it | |
| 19:20:11 | tbabel | so far i haven't been able to find any config options or even more info/docs around this workflow. I assumed it would have been the nova service user doing it as it's being saved on the compute node where other users can use it without running in to download image policy issues.. just trying to make sense of it all | |
| 19:20:51 | Uggla | gmaan kindly agree to run this topic, and he will be able to make a quick recap on Friday 16:30 UTC for EU folks. | |
| 19:20:51 | Uggla | nisha04, gmaan, dansmith, melwitt I have set a meeting US/JPN Friday 00:00 UTC for the graceful shutdown topic. Goal is to have a more friendly JPN timeframe as we promised during openinfra summit. I hope that it will work for you. | |
| 19:21:16 | melwitt | hm yeah, I see what you're saying. /me checks something | |
| 19:26:42 | dansmith | Uggla: er, probably not unless you really need me there | |
| 19:26:43 | melwitt | Uggla: thanks for the heads up | |
| 19:29:27 | melwitt | tbabel: I was just looking in the code and there is a GET /images as part of the create path which I guess serves as the policy check https://github.com/openstack/nova/blob/30bf8c1025ea24823ebde3eacede4ea34ec6be8c/nova/compute/api.py#L1040 however I appreciate that it is not the same as download permission. so if there is asymmetry there you could get inconsistent behavior as far as I can tell | |
| 19:30:07 | melwitt | depending on whether the image is cached on the compute host or not | |
| 19:31:39 | tbabel | Yeah, that's def what i'm seeing. If the image isn't cached and the user without roles to download the builds go to error with a 403 from glance. It'd be nice if there were a way to force the nova service user to do that operation. | |
| 19:32:00 | tbabel | I may have to do pre-caching to work around this and keep our policy in tact | |
| 19:35:09 | Uggla | dansmith, should be great if you could attend this meeting. But I know you are an early bird, so if it's too late I will understand | |
| 19:35:33 | gmaan | tbabel: melwitt I think nova use service user to talk to glance but need to check what policy are on glance side | |
| 19:37:14 | melwitt | tbabel: yeah I was about to suggest that, pre-caching seems like the only workaround at the moment. having an option like that sounds reasonable to me, i.e. it is reasonable for a deployer to have different permissions for download vs get | |
| 19:37:49 | melwitt | *having an option to make nova service user do image downloads to computes | |
| 19:38:41 | tbabel | agreed! | |
| 19:38:46 | melwitt | gmaan: yeah I wondered that but AFAICT it is the calling user, not the nova user | |
| 19:39:06 | melwitt | if you find otherwise please link me bc I missed it :) | |
| 19:39:43 | tbabel | it's possible that nova initiates the call with a service user but checks the permissions | |
| 19:40:07 | tbabel | because i can change the role on the user and make it work, so it's not using the nova service user solely | |
| 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 ? | |