| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-17 | |||
| 17:32:34 | sean-k-mooney | i feel like if we do it will be a https://xkcd.com/1172/ and i tink im ok with that | |
| 17:40:45 | gmaan | sean-k-mooney: seeing it is admin currently, it should be very noticeable that what they are doing but I will not be against of blocking it via policy. | |
| 17:40:53 | gibi | sean-k-mooney: pretty much yes :) | |
| 17:41:06 | gmaan | but I think we should remove it or restrict it in some separate seciton in api-ref | |
| 17:41:53 | sean-k-mooney | gmaan: well changing the policy is the more consrevity change i actully want to deltee that api | |
| 17:42:33 | gmaan | sean-k-mooney: I am up to delete it. I am not sure what all cases it was helpful but it can/has been distructive in many cases | |
| 17:43:02 | sean-k-mooney | gmaan: i twas orgianlly added to help when your stuck in an intermediate state | |
| 17:43:53 | sean-k-mooney | most of the time the fix is hard-reboot or delete dependign on the state | |
| 17:44:01 | gmaan | yeah | |
| 17:44:04 | sean-k-mooney | i.e. if your stuck in buildign then delete | |
| 17:44:47 | sean-k-mooney | if we changed defautl policy we coudl get feedback form operators before commitign one way or another | |
| 17:46:41 | sean-k-mooney | i added --auto-approve and made it request an interactive approve in osc recently https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-set-auto-approve | |
| 17:47:25 | gmaan | sure, that will help at least to know if people want it or we can delete it. at least keep it restrictive for some cycles and if any one ask for it at least then it is not good to delete | |
| 17:47:30 | sean-k-mooney | so not it at least asks you are you sure before it will do reset state | |
| 17:47:44 | sean-k-mooney | s/not/now/ | |
| 17:47:49 | gmaan | sean-k-mooney: yeah I saw that . ++ that was good from ux side | |
| 17:49:32 | gmaan | sean-k-mooney: if dis-allow in policy, do we need to remove/change anything from client? or nova error about unauthorized is enough for admin to know what they need to do | |
| 17:49:58 | gmaan | I want to avoid if it create confusion over error messgage or they think it is gone | |
| 17:53:44 | sean-k-mooney | no it will just get a 401 of 403 | |
| 17:54:00 | sean-k-mooney | same as any other policy error | |
| 17:54:16 | sean-k-mooney | granted im not sure it will say its becuase of policy but it may | |
| 17:54:37 | sean-k-mooney | i woudl have to check if we have a generic policy message that will be show to the end user. | |
| 17:55:25 | sean-k-mooney | gmaan: i dont think we have any special client side code for cross cell resize witch is the only case we disallow everyone today | |
| 17:56:22 | gmaan | cool | |
| 18:05:11 | ozzzo | If I have VMs that were built with host-passthrough and now we are replacing hardware and we need to live-migrate to the new hypervisors, is it possible to make the new hypervisors emulate the old CPU so that live-migration can work? | |
| 18:05:50 | sean-k-mooney | ozzzo: no not really | |
| 18:06:13 | sean-k-mooney | if its actully compatible then the migration will jsut work form the old host to the new host | |
| 18:06:24 | sean-k-mooney | but once the vm is rebooted on the new host it wont be able to move back | |
| 18:06:58 | ozzzo | we tried it but the filter appears to be rejecting; it says "no valid host" | |
| 18:07:00 | sean-k-mooney | host-passthrough at least the way it work in nova today exposed too much of the underlying host cpu details | |
| 18:07:13 | ozzzo | This is in wallaby | |
| 18:09:47 | sean-k-mooney | ya that woudl not fix it. what i was refering too is new livberit ahs a new semi-mode | |
| 18:10:02 | sean-k-mooney | basiclly you can say host-passthough + live migratable | |
| 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 | |