Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-29
16:15:58 tkajinam :-P
16:52:49 gibi I guess we break until the top of the hour
17:03:14 bauzas Uggla: where is the nova-neutron discussion ?
17:03:21 bauzas I joined the neutron room but I was alone
17:03:45 Uggla nop it is manilla one
17:03:48 Uggla on our room
17:03:57 Uggla bauzas ^
17:25:08 dansmith Uggla: is there a link to the room somewhere? I'm missing it
17:26:09 bauzas Uggla: I think we could discuss the AZ-soft-anti-affinity topic from noonedeadpunk at the very beginning of the nova sessions tomorrow
17:26:30 Uggla dansmith: https://meetpad.opendev.org/oct2025-ptg-neutron
17:26:46 bauzas 2 hours for confidential computing topics seems to be good, but we could throw 30 mins from that and give it to the AZ thing
17:27:26 Uggla bauzas, I agree but more at the end. Because confidential computing owners are located in Japan
17:27:31 dansmith Uggla: thanks, might be good to have these all linked
17:27:56 Uggla dansmith, https://ptg.opendev.org/ptg.html
17:28:15 dansmith I know where to find them, I mean on the etherpad :)
17:28:32 Uggla dansmith, you are a bit hard with me today. :)
17:30:24 dansmith not intending to be
17:40:53 noonedeadpunk bauzas: Uggla would be great to get info about timing today, as it would highly influence my plans for tomorrow (need to have a 8h drive during tomorrow, so need to schedule it or stops)
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

Earlier   Later