| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-29 | |||
| 12:55:38 | cardoe | Along with tests and tests for tempest which depend on the change to nova. | |
| 12:56:37 | cardoe | There’s additional tests for neutron as well and bug fixes for some corner cases with neutron and its trunk handling. | |
| 12:56:41 | TheJulia | ... yeah, I remember now | |
| 12:56:49 | TheJulia | I had to fix the tests from blindly running | |
| 12:57:22 | cardoe | Neutron accepted the change to tighten up the spec on their side as well. | |
| 12:58:49 | cardoe | It was a series of patches developed by Mirantis, Red Hat and another company. The unnamed company is who I pressed on their CTO to stop developing OpenStack downstream and get involved upstream. To pus their developers to join the projects. | |
| 13:00:48 | cardoe | I naively said I just got elected to the TC. Let me show you how it’s not hard to engage the community and get a benefit from that. I thought this has a spec and patches written by a group covering multiple companies. It’ll be easy. | |
| 13:02:45 | cardoe | I pointed the CTO to asks by projects for more people to get engaged. He told me their work just gets ignored. I thought I could get more developers to engage nova and neutron. | |
| 13:03:19 | cardoe | I was proven wrong. | |
| 13:42:41 | Uggla | Info: Start of PTG session in ~20mn | |
| 13:42:50 | Uggla | Topic: Discuss if the CPU comparison beetween src host and dst host can not be improved or is it still relevent ? | |
| 14:03:22 | nisha04 | uggla: Hi regarding the session schedule on etherpad. Japan morning with US folks also works for me. I can also join the original PTG timeslot (14:00 to 18:00 UTC) on Thu/Fri if the morning session is difficult. What do you think? | |
| 14:50:35 | nicolairuckel | How can I see which room I have to join for my topic? | |
| 14:50:44 | nicolairuckel | For the PTG | |
| 14:51:27 | nicolairuckel | Uggla, do I just join the Nova room? | |
| 14:51:39 | auniyal | https://ptg.opendev.org/ptg.html - | |
| 14:51:46 | auniyal | you can join here https://meetpad.opendev.org/nova-2026.1-ptg | |
| 14:52:11 | nicolairuckel | thanks! | |
| 14:52:21 | Uggla | nicolairuckel, yes please join using the link above from auniyal | |
| 14:52:38 | Uggla | We are still in the cinder/nova x team session. | |
| 15:41:39 | opendevreview | melanie witt proposed openstack/nova master: libvirt: add configuration option for volume AIO mode https://review.opendev.org/c/openstack/nova/+/964848 | |
| 15:46:06 | opendevreview | melanie witt proposed openstack/nova master: libvirt: add configuration option for volume AIO mode https://review.opendev.org/c/openstack/nova/+/964848 | |
| 16:05:17 | dansmith | Uggla: man, feels like this is not the best use of nova's time, eh? | |
| 16:07:37 | Uggla | dansmith it was not what was expected. | |
| 16:08:25 | Uggla | cinder should join later. | |
| 16:08:27 | dansmith | were there specific topics we were supposed to be getting discussed? because if so, we should probably decide if we're going to discuss those and if not, bail | |
| 16:08:32 | dansmith | cinder is on the call | |
| 16:08:41 | dansmith | this is all ironic->cinder discussion AFAICT | |
| 16:11:34 | Uggla | yep they have requested us too. But I agree. | |
| 16:11:56 | Uggla | I just hope this topic will stop soon to discuss ours. | |
| 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 | 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: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: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 | |