Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-29
17:41:48 bauzas noonedeadpunk: what would be your preference time-wise ?
17:42:52 noonedeadpunk I think closer to the end would be better for me...
17:43:10 noonedeadpunk but probably can do 14 utc as well
17:43:54 noonedeadpunk I'm more flexible today then I'll be tomorrow :D
17:44:17 noonedeadpunk 15/16 utc slots are least convenient
17:44:40 Uggla noonedeadpunk, I think we can have something Thu around 15h30/15/45 --> 1600 UTV
17:44:47 Uggla *UTC
17:45:28 Uggla or Friday 16:30 UTC
17:45:51 noonedeadpunk friday 16-30 conflicts with TC
17:46:41 Uggla Friday 15:30 ?
17:47:05 noonedeadpunk works for me, yes
17:47:36 Uggla noonedeadpunk sold I will try to update the schedule to reflect that.
17:47:43 noonedeadpunk ++ thanks!
17:48:27 noonedeadpunk if you'll be re-shuffling schedule on Friday - I have another topic for there already
17:49:06 noonedeadpunk so if they could be relatively together - that would be grand
17:56:27 tbabel Hello, looking for help wrapping my head around instance boot workflow. In particular i'm curious how the image is downloaded to a compute node(in the event it doesn't exist). Does it use the nova service user or possibly user credentials themselves? Asking because i'm trying to resolve a glance/image polilcy issue and not quite sure where to target a fix at this point. Any tips are greatly appreciated!
17:58:51 bauzas Uggla: nice try for letting people hearing French
17:59:23 Uggla ?
17:59:38 bauzas but I'd propose you to cut your mic, there are other ways to learn French
18:00:00 Uggla just realize it was open, sorry about that
18:00:20 Uggla I hope it was not too much disturbing
18:39:27 opendevreview Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584
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

Earlier   Later