| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-17 | |||
| 18:10:09 | sean-k-mooney | which exposes a tiny bit less | |
| 18:10:25 | sean-k-mooney | master cant do that today | |
| 18:10:43 | sean-k-mooney | ozzzo: have you conisered cold migration instead | |
| 18:11:56 | sean-k-mooney | did anyoen hwave time to look at my spec today by the way https://review.opendev.org/c/openstack/nova-specs/+/951222 | |
| 18:12:17 | sean-k-mooney | i dont see any comment form others | |
| 18:14:33 | sean-k-mooney | i still have -w on ti becaues i planned ot make some minor chagnes to wording but its been ready for review for 3 weeks now so im looking for some input on the general direction before inveting more time into it :) | |
| 18:23:49 | sean-k-mooney | gibi: by the way i think its very possibel that we may end up supprotign diffent python versoin dependign on if eventlet is enabeld or not next cycle | |
| 18:24:01 | sean-k-mooney | i.e. we may only supprot 3.13 in threaded mode | |
| 18:24:21 | sean-k-mooney | and not supprot it in eventlet mode ever if eventlet does not get fixed | |
| 18:24:47 | sean-k-mooney | our unit and fucntional test run fine under 3.13 | |
| 18:25:06 | sean-k-mooney | regardless of eventlet so that unfrotuently does not help us... | |
| 18:25:43 | sean-k-mooney | i think thats because of how our fixture work with regards ot things like the neutron client | |
| 21:23:00 | ozzzo_home | @sean-k-mooney: That's what I was hoping to avoid; this is a prod region, but it looks like TINA | |
| 21:34:03 | sean-k-mooney | ozzzo_home: there is one thing you could try. | |
| 21:34:23 | sean-k-mooney | ozzzo_home:nova is a littel stricter then libvirt in how we compare the compatiabltiyof the cpus | |
| 21:35:21 | sean-k-mooney | ozzzo_home: you could enable https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_cpu_compare_on_dest | |
| 21:35:48 | sean-k-mooney | this will disable novas cpu compatiablity check in pre live migrate | |
| 21:35:54 | sean-k-mooney | and fall back to libvirts one in migrate | |
| 21:36:07 | sean-k-mooney | its more expensive to do that which is why we dont rely on it | |
| 21:36:39 | ozzzo_home | ok I'll try it, ty! | |
| 21:36:42 | sean-k-mooney | bug its somethign you could try at least for a short period of time to move insteas to the new hardway | |
| 21:36:45 | sean-k-mooney | *hardware | |
| 21:37:06 | sean-k-mooney | tehre are are few other related options just below it | |
| 21:37:11 | sean-k-mooney | like https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_hypervisor_version_check_on_lm | |
| 21:37:36 | sean-k-mooney | we dont actully allow moving form a newer livirt/qemu to and older one but you can turn that off | |
| 21:38:05 | sean-k-mooney | you can also turn off the startup cpu comaptibaltiy check https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_cpu_compare_at_startup | |
| 21:38:22 | sean-k-mooney | again i dont advice doing that as you will only findout yoru config is wrong when you try to boot a vm | |
| 21:38:36 | sean-k-mooney | but in very rare cases those can be sueful for working around libvirt bugs | |
| 21:38:42 | sean-k-mooney | or upgrade issues | |
| 21:39:00 | sean-k-mooney | skip_cpu_compare_on_dest is your best bet | |
| 22:03:24 | ozzzo_home | sean-k-mooney: Will that work in Wallaby? I don't find it in the wallaby doc | |
| #openstack-nova - 2025-06-18 | |||
| 00:13:31 | gmaan | sean-k-mooney: about cyborg, TC decided to mark it inactive and I sent email also to call out new maintainers if anyone interested https://review.opendev.org/c/openstack/governance/+/952798 | |
| 00:14:27 | gmaan | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3QZML3MGTSJOWJY72ZM75VIRQA5ZRXBC/ | |
| 00:14:55 | gmaan | if we merge the inactive status change, then we can remove the cyborg job also from nova gate | |
| 03:03:09 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | |
| 03:03:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | |
| 03:03:31 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | |
| 03:03:37 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | |
| 08:56:40 | opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754 | |
| 09:02:12 | mikal | sean-k-mooney: you around? | |
| 10:06:06 | gibi | sean-k-mooney: yeah having a statement that if you need eventlet based nova then you need to use py3.12 or older. Still it does not help debian and ubuntu to have something that work with 3.13 soon. My estimate is that in best case scenario we have nova supporting 3.13 at the 2026.1 but that need serious focus from the core team. 2026.2 is more likely target as it is likely that nova-comptue will not | |
| 10:06:12 | gibi | fit into a single cycle. | |
| 10:08:32 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: Show finish_time field in instance action show https://review.opendev.org/c/openstack/nova-specs/+/929780 | |
| 10:15:32 | gibi | or we can hope Herve and the eventlet maintainers figure something out to support eventlet in 3.13 | |
| 10:22:14 | opendevreview | Lajos Katona proposed openstack/os-vif stable/2024.2: Do not add taps in trunk bridges to the dead vlan https://review.opendev.org/c/openstack/os-vif/+/952815 | |
| 10:27:17 | opendevreview | Lajos Katona proposed openstack/os-vif stable/2024.2: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/952778 | |
| 10:29:22 | sean-k-mooney | gibi: im partly wondering if nova-comptue will need to be doen on a per driver basis | |
| 10:29:36 | sean-k-mooney | gibi: i think nova-comptue with ironic/fake shoudl be a lot simpler | |
| 10:29:58 | sean-k-mooney | i cant say for vmware but libvirt driver is where i think most of the work will be | |
| 10:30:38 | sean-k-mooney | given it has all the extra logic for ceph and libvirt native thread and the ovsdb background connection ectra | |
| 10:31:21 | sean-k-mooney | the fake and ironic dirver have none of that so those might be able to prove out the core of the manager ectra first | |
| 10:31:38 | sean-k-mooney | but ya i can see it takeing more then 1 cycle | |
| 10:35:15 | gibi | sean-k-mooney: yeah it might make sense to do driver by driver. We can do an initial try with the fake driver very early | |
| 10:35:50 | gibi | I haven't looked at the ironic and other non libvirt drivers but I agree that they should be not too complex to handle. | |
| 10:36:10 | gibi | still libvirt driver is th most valuable | |
| 10:36:27 | sean-k-mooney | oh definetly | |
| 10:36:35 | sean-k-mooney | i was also talkign to JayF a littel | |
| 10:36:46 | sean-k-mooney | we deprecated peer_list | |
| 10:36:54 | sean-k-mooney | when we added the ironic shard support | |
| 10:37:00 | sean-k-mooney | but we have not deleted it yet | |
| 10:37:13 | sean-k-mooney | i think before we try to move the inronic driver we should nuke that code | |
| 10:37:48 | sean-k-mooney | because debuging moving compute nodes between compute serivce while converting to threaded is not something i want to wish on an enemy | |
| 10:38:00 | sean-k-mooney | let alone you or me for that matter | |
| 10:38:25 | sean-k-mooney | that is potirally something we could start on this cycle in adanvce if we had time | |
| 10:38:50 | sean-k-mooney | its pretty independet of the actual eventlet sereise and is mainly jsut removing code, docs and deps | |
| 10:49:25 | gibi | I'm not against removing code. I have no context about this actual removal but I'm happy to review the removal. Also if it seen as something that helps I can try to load context and do the removal myself but obvious reasons it would be easyer if the ironic folks propose the removal | |
| 10:55:24 | sean-k-mooney | gibi: no i have a lot on my plate right now in diffent context. some of those are going to hit spec freeze if they dont get reviewd so if that happens i might look at doing the removal | |
| 10:55:33 | sean-k-mooney | until we hit m2 i woudl not woryy about it | |
| 10:56:48 | sean-k-mooney | gibi: the wider context is we implemnge d ironic shardign supprot in caracal https://specs.openstack.org/openstack/nova-specs/specs/2024.1/implemented/ironic-shards.html so we are free to remove the old code which also allows us to remvoe taskflow as a dep in nova | |
| 10:59:52 | gibi | OK thanks for the pointr | |
| 12:30:02 | gokhan__ | Hi all, I have a question regarding attaching ISO images as CD-ROM devices to instances. I have an image in Glance with disk_format=iso and hw_cdrom_bus=ide set. I would like to attach it to a Windows instance as a CD-ROM so that Windows can see the contents (e.g. SQL Server setup files). I tried using --block-device with source_type=image, destination_type=local, device_type=cdrom, etc., but I get: "Mapping image to local is not supported".Is | |
| 12:30:02 | gokhan__ | there a supported way to attach a Glance ISO image as a CD-ROM device (non-bootable) to a running instance or at boot time? If not, is this a Nova limitation, or a backend/image format issue?Thanks in advance! | |
| 12:56:14 | sean-k-mooney | destination_type=local means do not use a cidner volume | |
| 12:56:36 | sean-k-mooney | and no there is not a way to do that today | |
| 12:57:36 | sean-k-mooney | wehn you create an instnace there is a way to add a cidner data volume created form an iso image in addtion too the boot disk, however there is no way to do it after the fact and its complex to do it a boot | |
| 12:58:34 | sean-k-mooney | currently there is no way to attch a cidner volume as a cdrom devicen so the only way to add an iso to a runnign vm is as a block device. | |
| 12:59:23 | sean-k-mooney | while its technically possibel to mount it in the guest with the right tools it wont work out of the box on say windows | |
| 13:00:18 | sean-k-mooney | gokhan__:you best bet would be to use rescue and boot from the iso do fix the issue and then unrescure to remove it | |
| 13:00:47 | sean-k-mooney | but if the iso is not a bootable image then thats not an option | |
| 13:01:26 | sean-k-mooney | in which case your only option would be ot use a normal cidner ovlume with a standar filesystem not and iso file system to sotre the data you want to preset to the runing guest | |
| 13:11:29 | gokhan__ | thanks sean-k-mooney , it seems the practical way is coply sql installation files to a cinder volume and using this. I tried also with virsh edit on compute node but it also didn't work. | |
| 14:59:04 | Vii | In OpenStack 2025.1, instance creation fails when there are two or more security groups with the same name in the same project. This occurs even if the security groups are not explicitly referenced during server creation (i.e., using only the default default security group). | |
| 14:59:10 | Vii | look: https://bugs.launchpad.net/nova/+bug/2114913 | |
| 15:00:26 | Vii | creating an instance from horizon also fails | |
| 21:28:32 | opendevreview | Ghanshyam proposed openstack/nova master: Add Project Manager role context in unit tests https://review.opendev.org/c/openstack/nova/+/941056 | |
| #openstack-nova - 2025-06-19 | |||
| 09:41:03 | jlejeune | hello, I'm also impacted by that bug : https://bugs.launchpad.net/nova/+bug/2084238, do you know if someone begin to work on it ? | |
| 10:03:55 | jlejeune | I confirm that a request-id is set for new instances (created after migration to 2023.1) but that field stays at NULL for instances created before the migration | |
| 10:03:57 | gibi | jlejeune: I don't know about any work on that | |
| 10:04:30 | jlejeune | ok thanks, maybe it's something the migration tools should take care | |
| 10:05:04 | jlejeune | to fill random request-id in for allocated devices | |
| 10:12:50 | gibi | jlejeune: i don't have the time to dig into it right now. But I think this is a valid bug that needs to be fixed | |
| 14:10:44 | opendevreview | ribaudr proposed openstack/nova master: Reproducer for bug 2114951 https://review.opendev.org/c/openstack/nova/+/952894 | |
| 14:10:44 | opendevreview | ribaudr proposed openstack/nova master: Fix bug 2114951 https://review.opendev.org/c/openstack/nova/+/952895 | |
| 14:33:01 | opendevreview | Andriy Kurilin proposed openstack/nova master: Reuse 'detail:get_all_tenants' policy in server get api https://review.opendev.org/c/openstack/nova/+/952896 | |
| 14:57:13 | sean-k-mooney | the request_id fucntionalty was added a very very long time ago | |
| 14:58:36 | sean-k-mooney | jlejeune: this feels like you skipped runnign an online data mighration | |
| 14:59:54 | sean-k-mooney | oh the one i was thinking of was a diffent fild https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L221 | |
| 15:00:05 | sean-k-mooney | its the uuid on the device not the requst id | |
| 15:01:22 | jlejeune | sean-k-mooney: exactly | |
| 15:02:31 | sean-k-mooney | the request id should alwasy be set in recent version of openstack | |