| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-17 | |||
| 17:01:59 | ildikov | Thanks y’all! | |
| 17:02:57 | Uggla | I wonder if we can postponed the open discussion to next week. There is a topic about Evacuate Action & InstanceInvalidState, but I don't know who entered it. | |
| 17:03:44 | fungi | while it may be an unpopular approach, the way a lot of open source projects (particularly volunteer-run communities) approach that challenge is by just saying that complaining only serves to burn out the handful of people keeping things going, and to either help shoulder their burden or go away | |
| 17:04:24 | Uggla | fungi++ completely true. | |
| 17:04:48 | fwiesel | Uggla: That would be me. Then maybe two weeks? | |
| 17:05:00 | fwiesel | In two weeks, I meant. | |
| 17:05:36 | Uggla | fwiesel, yes I keep the items and we will discuss it not next week but the week after. | |
| 17:05:48 | fwiesel | Uggla: Thanks. | |
| 17:05:52 | gibi | fungi: yeah then we need to figure out how they can effectivel help shouldering the burden | |
| 17:06:50 | Uggla | fwiesel, thanks you to understand. I don't want to keep people here anymore as we are already overtime. | |
| 17:07:02 | Uggla | Thanks all | |
| 17:07:15 | Uggla | #endmeeting | |
| 17:07:15 | opendevmeet | Meeting ended Tue Jun 17 17:07:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:07:15 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.html | |
| 17:07:15 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.txt | |
| 17:07:15 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.log.html | |
| 17:07:18 | gibi | Uggla: thanks | |
| 17:27:08 | sean-k-mooney | ^ that actully a ligiitmate suggestion | |
| 17:27:29 | sean-k-mooney | no mather how often we tell them ot never use it after a issue with a move operatiorn they still do | |
| 17:28:30 | sean-k-mooney | if we made them opt into it or had a "allow_foot_guns" role it would avodi lot of reset-state related pain | |
| 17:29:26 | sean-k-mooney | sort of like cephs --yes-i-really-mean-it flag to make them do just a littel bit more to do the unsafe thing | |
| 17:29:38 | gibi | sean-k-mooney: I'm supportive | |
| 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 | |