| *** mhen_ is now known as mhen | 03:00 | |
| yunhokim_ | Hi, compute_task.migrate_server notification has sent as error when vm migration failed due to lack of host. But resize also use same notification and payload. Can we add delimiter in payload to figure out which event occurs during migration or resize? | 07:40 |
|---|---|---|
| gibi | yunhokim_: resize and cold migrate is the same action internally in nova. A cold migrate is a resize without flavor change. The instance.resize_prep.start and instance.resize_prep.end notifications has an extra new_flavor field. If you compare the flavorid in the new_flavor and flavor fields and they are differ then the it is a resize, if they are the same then it is a cold migration. At the moment | 08:46 |
| gibi | this is the best we can do. If you want to improve on it we might be able to add the new_flavor fields to the rest of the resize notifications | 08:46 |
| yunhokim_ | Thanks for apply. I just find the code that you mentioned from conductor. I will check that can improve. | 09:59 |
| iurygregory | Hello nova folks, just a reminder that today at 15:30 UTC we have cross-project session with ironic, where? Mitaka room | 11:20 |
| sean-k-mooney | https://etherpad.opendev.org/p/nova-2026.1-ptg#L93 | 12:00 |
| sean-k-mooney | iurygregory: it says nova host in the grizzly room | 12:00 |
| sean-k-mooney | iurygregory:but that really means join https://meetpad.opendev.org/nova-2026.1-ptg | 12:00 |
| sean-k-mooney | since we are not using zoom rooms and are usign the meetpad/jitis rooms instead | 12:01 |
| iurygregory | sean-k-mooney, oh ok! | 12:12 |
| * iurygregory updates ironic etherpad | 12:13 | |
| sean-k-mooney | iurygregory:oh uyou sadi 15:30 | 12:13 |
| sean-k-mooney | iurygregory: for that we are in your room | 12:13 |
| sean-k-mooney | https://etherpad.opendev.org/p/nova-2026.1-ptg#L104 | 12:13 |
| sean-k-mooney | i looked at teh mainilla session sorry | 12:14 |
| iurygregory | oh ok | 12:14 |
| sean-k-mooney | iurygregory: so we shoudl be joining https://meetpad.opendev.org/oct2025-ptg-ironic at 15:30 | 12:14 |
| iurygregory | yeah | 12:14 |
| iurygregory | I will join the nova room to remind about it | 12:14 |
| sean-k-mooney | oh you were not askign where it is you were saying it was in mitaka before | 12:15 |
| iurygregory | yeah =) | 12:15 |
| sean-k-mooney | iurygregory: so im proably still going ot be in the watcher room at that point so i likely wont be able to attend but i think i replied in supprot fo the ironic topic on the ml? unless im misrememebring | 12:16 |
| sean-k-mooney | iurygregory: the restore backups to a different availability zone topic if for cinder right? | 12:17 |
| iurygregory | sean-k-mooney, you did | 12:17 |
| sean-k-mooney | given you cant use AZ with ironic really since you cant really use host aggartes with ironic | 12:17 |
| sean-k-mooney | on the nova side | 12:17 |
| sean-k-mooney | its proably less broken then it was in the past now that we supprot the ironic sharding feature | 12:18 |
| iurygregory | yeah, we only have two topics the graphical console and boot the machines from NVMe-over-TCP (nova+cinder) | 12:18 |
| sean-k-mooney | cool | 12:18 |
| iurygregory | feel free to add info in the etherpad if you want also | 12:18 |
| iurygregory | https://etherpad.opendev.org/p/ironic-ptg-2026.1#L667 | 12:18 |
| sean-k-mooney | iurygregory: this might be of relevence to ironichttps://review.opendev.org/c/openstack/nova-specs/+/471815 | 12:19 |
| iurygregory | sean-k-mooney, for which topic? | 12:20 |
| sean-k-mooney | although that more about supproting the vlan trunk info for neutron trunk ports in genreal in the metadata | 12:20 |
| sean-k-mooney | iurygregory: not for any of the current ones it just hat mentionign it because one of the use cases is "Once the BM server is booted up with Ironic, its networking interfaces can be | 12:20 |
| sean-k-mooney | automatically configured and brought up." | 12:20 |
| sean-k-mooney | iurygregory: i belive ye implented a feature very much like this on your side in the last release or twoo so this may now onlybe relevent to other virt drivers | 12:21 |
| sean-k-mooney | just sharing for awareness | 12:21 |
| iurygregory | ack | 12:26 |
| iurygregory | tks sean-k-mooney | 12:26 |
| iurygregory | fyi TheJulia ^ | 12:26 |
| TheJulia | cardoe: w/r/t the spec sean mentioned, any n-g-s impact anticipated? | 12:49 |
| cardoe | The vlan trunk? No | 12:50 |
| cardoe | We run the patches and Mirantis runs the patches in prod for well over a year. | 12:50 |
| TheJulia | but shouldn't there be switch configuration to represent it? | 12:50 |
| cardoe | Of course. But this is about passing the trunk port data to the server so it knows how to configure its interfaces. | 12:51 |
| sean-k-mooney | TheJulia: the vlan that is presented to the guest is a public atibute of neutorn turnk prot api meaning the end user get to choose it | 12:51 |
| cardoe | This is just representing what’s in neutron to the server. | 12:51 |
| sean-k-mooney | n-g-s would have to cofnigure that mapping on the switch port | 12:51 |
| sean-k-mooney | but that seperate form passing the infor to the vm in the metadta | 12:52 |
| cardoe | Exactly | 12:52 |
| TheJulia | Okay, looks like there is already code there to handle trunks specifically | 12:54 |
| cardoe | TheJulia: https://github.com/openstack/networking-generic-switch/blob/master/networking_generic_switch/trunk_driver.py | 12:54 |
| cardoe | There's the implementation of n-g-s handling it already. | 12:54 |
| TheJulia | yeah, I found that and in the mech driver, I just haven't had time and caffination to compeltely wrap my head around it so far this morning | 12:54 |
| TheJulia | Anyway, thanks for the quick responses! | 12:54 |
| cardoe | Yeah we implemented this ages ago in there. | 12:55 |
| cardoe | Along with tests and tests for tempest which depend on the change to nova. | 12:55 |
| cardoe | There’s additional tests for neutron as well and bug fixes for some corner cases with neutron and its trunk handling. | 12:56 |
| TheJulia | ... yeah, I remember now | 12:56 |
| TheJulia | I had to fix the tests from blindly running | 12:56 |
| cardoe | Neutron accepted the change to tighten up the spec on their side as well. | 12:57 |
| 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. | 12:58 |
| 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:00 |
| 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:02 |
| cardoe | I was proven wrong. | 13:03 |
| Uggla | Info: Start of PTG session in ~20mn | 13:42 |
| Uggla | Topic: Discuss if the CPU comparison beetween src host and dst host can not be improved or is it still relevent ? | 13:42 |
| 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:03 |
| nicolairuckel | How can I see which room I have to join for my topic? | 14:50 |
| nicolairuckel | For the PTG | 14:50 |
| nicolairuckel | Uggla, do I just join the Nova room? | 14:51 |
| auniyal | https://ptg.opendev.org/ptg.html - | 14:51 |
| auniyal | you can join here https://meetpad.opendev.org/nova-2026.1-ptg | 14:51 |
| nicolairuckel | thanks! | 14:52 |
| Uggla | nicolairuckel, yes please join using the link above from auniyal | 14:52 |
| Uggla | We are still in the cinder/nova x team session. | 14:52 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: add configuration option for volume AIO mode https://review.opendev.org/c/openstack/nova/+/964848 | 15:41 |
| 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 |
| dansmith | Uggla: man, feels like this is not the best use of nova's time, eh? | 16:05 |
| Uggla | dansmith it was not what was expected. | 16:07 |
| Uggla | cinder should join later. | 16:08 |
| 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 |
| dansmith | cinder is on the call | 16:08 |
| dansmith | this is all ironic->cinder discussion AFAICT | 16:08 |
| Uggla | yep they have requested us too. But I agree. | 16:11 |
| Uggla | I just hope this topic will stop soon to discuss ours. | 16:11 |
| tkajinam | :-P | 16:15 |
| gibi | I guess we break until the top of the hour | 16:52 |
| bauzas | Uggla: where is the nova-neutron discussion ? | 17:03 |
| bauzas | I joined the neutron room but I was alone | 17:03 |
| Uggla | nop it is manilla one | 17:03 |
| Uggla | on our room | 17:03 |
| Uggla | bauzas ^ | 17:03 |
| dansmith | Uggla: is there a link to the room somewhere? I'm missing it | 17:25 |
| 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 |
| Uggla | dansmith: https://meetpad.opendev.org/oct2025-ptg-neutron | 17:26 |
| 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:26 |
| Uggla | bauzas, I agree but more at the end. Because confidential computing owners are located in Japan | 17:27 |
| dansmith | Uggla: thanks, might be good to have these all linked | 17:27 |
| Uggla | dansmith, https://ptg.opendev.org/ptg.html | 17:27 |
| dansmith | I know where to find them, I mean on the etherpad :) | 17:28 |
| Uggla | dansmith, you are a bit hard with me today. :) | 17:28 |
| dansmith | not intending to be | 17:30 |
| 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:40 |
| bauzas | noonedeadpunk: what would be your preference time-wise ? | 17:41 |
| noonedeadpunk | I think closer to the end would be better for me... | 17:42 |
| noonedeadpunk | but probably can do 14 utc as well | 17:43 |
| noonedeadpunk | I'm more flexible today then I'll be tomorrow :D | 17:43 |
| noonedeadpunk | 15/16 utc slots are least convenient | 17:44 |
| Uggla | noonedeadpunk, I think we can have something Thu around 15h30/15/45 --> 1600 UTV | 17:44 |
| Uggla | *UTC | 17:44 |
| Uggla | or Friday 16:30 UTC | 17:45 |
| noonedeadpunk | friday 16-30 conflicts with TC | 17:45 |
| Uggla | Friday 15:30 ? | 17:46 |
| noonedeadpunk | works for me, yes | 17:47 |
| Uggla | noonedeadpunk sold I will try to update the schedule to reflect that. | 17:47 |
| noonedeadpunk | ++ thanks! | 17:47 |
| noonedeadpunk | if you'll be re-shuffling schedule on Friday - I have another topic for there already | 17:48 |
| noonedeadpunk | so if they could be relatively together - that would be grand | 17:49 |
| 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:56 |
| bauzas | Uggla: nice try for letting people hearing French | 17:58 |
| Uggla | ? | 17:59 |
| bauzas | but I'd propose you to cut your mic, there are other ways to learn French | 17:59 |
| Uggla | just realize it was open, sorry about that | 18:00 |
| Uggla | I hope it was not too much disturbing | 18:00 |
| 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 | 18:39 |
| melwitt | tbabel: I think it would be the user's credentials (the one creating a new instance) | 19:16 |
| 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:18 |
| 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 |
| 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 |
| 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 |
| 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 |
| melwitt | hm yeah, I see what you're saying. /me checks something | 19:21 |
| dansmith | Uggla: er, probably not unless you really need me there | 19:26 |
| melwitt | Uggla: thanks for the heads up | 19:26 |
| 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:29 |
| melwitt | depending on whether the image is cached on the compute host or not | 19:30 |
| 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:31 |
| tbabel | I may have to do pre-caching to work around this and keep our policy in tact | 19:32 |
| 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 |
| gmaan | tbabel: melwitt I think nova use service user to talk to glance but need to check what policy are on glance side | 19:35 |
| 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 |
| melwitt | *having an option to make nova service user do image downloads to computes | 19:37 |
| tbabel | agreed! | 19:38 |
| melwitt | gmaan: yeah I wondered that but AFAICT it is the calling user, not the nova user | 19:38 |
| melwitt | if you find otherwise please link me bc I missed it :) | 19:39 |
| tbabel | it's possible that nova initiates the call with a service user but checks the permissions | 19:39 |
| 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:40 |
| 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:45 |
| tbabel | drats! Thanks for helping confirm! | 19:47 |
| 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 |
| gmaan | we do it for other service like neutron and cinder but not for glance. I think we missed it. | 19:50 |
| 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:51 |
| gmaan | and glance needs to make GET image for service role also. Currently glance does not allow it for service role | 19:52 |
| tbabel | gmaan: Thank you! | 19:54 |
| 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:56 |
| 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 | 19:59 |
| melwitt | gmaan: yeah makes sense | 20:00 |
| 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:04 |
| 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:07 |
| 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:08 |
| 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 |
| melwitt | so I dunno | 20:09 |
| gmaan | 'but don't want them to download_image.' you mean even cache in compute right? even that is internal compute workflow | 20:09 |
| gmaan | yeah, it seems tricky if service user should dowload it for them | 20:10 |
| 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 |
| melwitt | ah, ok | 20:10 |
| gmaan | i see | 20:10 |
| tbabel | maybe we need another glance policy or something along those lines | 20:11 |
| melwitt | that makes sense actually. image binary content is the property of the cloud but users can still make VMs | 20:11 |
| melwitt | I guess if they made a VM with that image then they have the content anyway? I dunno | 20:11 |
| melwitt | either way good for PTG discussion I think :) | 20:12 |
| gmaan | yeah or snapshot VM or other hack:) | 20:12 |
| clarkb | melwitt: yes it seems liek you could just dd the data off of disk | 20:12 |
| melwitt | yeah | 20:12 |
| tbabel | great question tbh, i'd have to prod the folks on my side further about the desire to block the download | 20:13 |
| 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 |
| gmaan | Uggla: ^^ | 20:28 |
| gmaan | feel free to update/add if something i missed | 20:28 |
| melwitt | thanks gmaan | 20:29 |
| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/961564 | 21:59 |
| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/961564 | 22:44 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!