Earlier  
Posted Nick Remark
#openstack-nova - 2025-09-09
16:50:22 gibi not a call form neutron to os-vif
16:50:34 sean-k-mooney ack well as i said we may be able to catch that excption and retry a limtied number of tiem in os-vif
16:50:43 sean-k-mooney kind of like we do for powering off cores
16:50:48 gibi sure. I rather want pyroute2 to fix the async code
16:50:49 sean-k-mooney btu i know neutron uses it more widely
16:51:09 gibi anyhow I have nothing further on this
16:52:17 elodilles (i added this to release team's weekly meeting's agenda for Friday, but i really hope that this will be sorted out until then :S)
16:53:02 gibi no worries I think we can go out with Flamingo even if the bug is there. Occasional failures that are fixed by the human retrying is not an end of the world
16:53:27 gibi elodilles: thanks!j
16:53:54 elodilles gibi: thanks too in advance for your mail to ML about this
16:55:03 Uggla good, anything else ?
16:55:43 tkajinam I was wondering if I could get any thoughts for https://bugs.launchpad.net/nova/+bug/2122296 . we don't have enough time and I likely skip the meeting next week but we can discuss it later here or the meeting in 2 weeks
16:56:20 tkajinam that's about sateless firmware but I also want to discuss similar problem with sev/sev-es, too
16:56:45 sean-k-mooney i belive we had a similar situration with secure boot before
16:57:19 sean-k-mooney i.e. if you enabel uefi adn dont reqeust secure boto we shoudl not use the SB+SMM one right
16:57:30 tkajinam yeah
16:57:31 tkajinam we have firmware detection logic for secure boot now so I'm wondering if I should follow that pattern.
16:57:46 tkajinam though this means that we may break existing usage with firmware without explicit support declared
16:58:09 tkajinam (I feel like such usage would be anyway broken but want to hear any opinion about it
16:58:13 sean-k-mooney ya i dont have context loaded but i think that would be a good thing to fix eventually
16:58:36 tkajinam this is just for early heads-up
16:59:16 sean-k-mooney we cant rely on libvirt to select it?
16:59:29 tkajinam we can, though that would be a huge change
16:59:29 sean-k-mooney i vagely recall that being a thing in newer relases
16:59:47 sean-k-mooney ack. that is prbaly the correct long term solution
16:59:47 tkajinam libvirt is now capable to select a correct firmware with only flags provided
17:00:00 tkajinam Uggla, I think we can wrap up the call (unless anyone else has additional topics)
17:00:11 tkajinam s/call/meeting/
17:01:02 Uggla ok time to close. Thanks everyone.
17:01:09 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-09-16.03.txt
17:01:09 Uggla #endmeeting
17:01:09 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-09-16.03.log.html
17:01:09 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-09-16.03.html
17:01:09 opendevmeet Meeting ended Tue Sep 9 17:01:09 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:01:23 gibi Uggla: thanks
17:01:24 elodilles thanks o/
17:02:04 tkajinam thanks !
17:02:12 Uggla you are welcome
17:03:54 opendevreview Merged openstack/osc-placement stable/2025.2: Update .gitreview for stable/2025.2 https://review.opendev.org/c/openstack/osc-placement/+/959744
17:06:05 sean-k-mooney elodilles: just an fyi i have created a watcher release note prelude and will be proposing the cycle hights for it soon. once that is done i think we are also mostly done with watcher release artifacts
17:06:23 sean-k-mooney elodilles: my hope is to have those both merged before rc1 is created on thursday
17:08:57 gibi Uggla: FYI I've just approved https://review.opendev.org/c/openstack/nova/+/959604 As I consider the content to be safe to land close to RC1. We have extensive discussion about the solution on IRC last week
17:09:18 gibi s/have/had/
17:09:39 Uggla gibi, thx and sorry for the mistake in the meeting. :)
17:10:09 gibi Uggla: no worries
17:13:15 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
17:15:56 opendevreview Merged openstack/osc-placement stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2 https://review.opendev.org/c/openstack/osc-placement/+/959745
17:18:34 opendevreview Nell Jerram proposed openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284
17:19:50 opendevreview Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688
17:19:51 opendevreview Stephen Finucane proposed openstack/nova master: Migrate codespell configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953704
17:19:51 opendevreview Stephen Finucane proposed openstack/nova master: Migrate mypy configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953703
17:19:52 opendevreview Stephen Finucane proposed openstack/nova master: Migrate setup configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953705
17:25:07 opendevreview Takashi Kajinami proposed openstack/nova master: Update libvirt version support matrix for Flamingo https://review.opendev.org/c/openstack/nova/+/960301
17:25:29 opendevreview Takashi Kajinami proposed openstack/nova master: docs: Update libvirt version support matrix for Flamingo https://review.opendev.org/c/openstack/nova/+/960301
17:25:40 tkajinam ^^^ this might be worth merging before rc1
19:12:51 elodilles sean-k-mooney: ACK, will check those tomorrow, thanks for the heads up o/
#openstack-nova - 2025-09-10
07:53:21 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
08:40:02 opendevreview ribaudr proposed openstack/nova master: Add Flamingo prelude section https://review.opendev.org/c/openstack/nova/+/959188
09:26:05 opendevreview Julien LE JEUNE proposed openstack/nova master: Adds regression test for bug LP#2044235 https://review.opendev.org/c/openstack/nova/+/960349
09:33:34 Uggla zigo would you be able to rebase your patch 930444: Update Debian qemu/libvirt/libguestfs versions | https://review.opendev.org/c/openstack/nova/+/930444 on top of the one from tkajinam (https://review.opendev.org/c/openstack/nova/+/960301) ?
09:46:09 opendevreview Takashi Kajinami proposed openstack/nova master: Update Debian qemu/libvirt/libguestfs versions https://review.opendev.org/c/openstack/nova/+/930444
09:46:26 tkajinam Uggla zigo, I've rebased it. I also modified it a bit because Trixie is already GA (UUIC)
09:46:57 Uggla tkajinam 👍
09:48:21 zigo tkajinam: Great, thanks a lot !
09:49:06 zigo This lists versions of qemu, libvirt and so on, right?
09:52:00 zigo Got it: https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html :)
10:03:39 opendevreview Merged openstack/nova master: docs: Update libvirt version support matrix for Flamingo https://review.opendev.org/c/openstack/nova/+/960301
11:29:23 sean-k-mooney tkajinam: it is but it wont offilaly be supproted until next cycle aka friday
11:30:24 sean-k-mooney tkajinam: once master is reopend im hoping ot finish the work that was started to supprot it in devstack and swap the nova-hybird-plug job form 12 to 13
11:32:15 tkajinam sean-k-mooney, yeah that's true
11:32:20 tkajinam due to python version
11:33:12 sean-k-mooney https://review.opendev.org/c/openstack/devstack/+/954653
11:33:21 sean-k-mooney tkajinam: no
11:33:36 sean-k-mooney becuase we select the supproted plathforms before the release starts
11:33:47 sean-k-mooney and it was not release at the start of 2025.2
11:33:58 sean-k-mooney openstack seams to work fine on it
11:33:58 tkajinam yeah that's true
11:34:07 sean-k-mooney but it will be an offical testign runtime form friday
11:34:12 tkajinam though I thought Trixie uses python 3.13
11:34:28 tkajinam I understand what you mean
11:37:02 opendevreview Merged openstack/nova master: hypervisors: Optimize uptime retrieval for better performance https://review.opendev.org/c/openstack/nova/+/959604
11:37:15 opendevreview Merged openstack/nova master: Update Debian qemu/libvirt/libguestfs versions https://review.opendev.org/c/openstack/nova/+/930444
11:43:41 opendevreview Julien LE JEUNE proposed openstack/nova master: Adds regression test for bug LP#2044235 https://review.opendev.org/c/openstack/nova/+/960349
11:56:06 gibi Uggla: sean-k-mooney: elodilles: I've sent the question about pyroute2 req rollback to ML and proposed the req patch. https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/FFYMQTJPJREQZ2P32HGS5HE2NLTXHVUC/ and https://review.opendev.org/c/openstack/requirements/+/960366
12:05:06 zigo Your thoughts ?
12:05:06 zigo So I wonder, would the team agree for a feature to disallow spawning an instance with boot from volume, if it is with a flavor that has a system disk? Of course, that would be only an option (or a policy ?) and we could keep the usual old (permissive) behavior of the Nova API.
12:05:06 zigo However, there's a problem when customers are doing a boot from volume, and select a flavor that includes a system disk. In this case, they get billed for something they will never be able to use.
12:05:06 zigo At my company, we bill instances depending on their resources. ie: if you want a 20GB system disk, you get billed (linearly) for it. Nothing special here.
12:05:06 zigo Hi there!
12:12:10 elodilles gibi: ACK, thanks o/ let's see if we get an answer for req folks
12:12:19 elodilles s/for/from
12:43:05 sean-k-mooney zigo: just reading back
12:44:13 sean-k-mooney zigo: what do you mean by 20GB system disk, do you mean a flavor with nova provisioned storage i.e. root_GB and/or ephmeral_GB >0
12:45:34 sean-k-mooney zigo: i advocated for blockign BFV instnace form using flavor with root_gb >0 when we prevented non boot form volume instance using flavors with root_gb=0
12:45:57 sean-k-mooney zigo: in the past it was consier too large of a upgrade impact for exisign clouds to make that change
12:46:15 sean-k-mooney zigo: i dont think we can jsut block it. but what we coudl do is add a policy rule for it
12:46:39 sean-k-mooney we have a policy rule for allowing non BFV guest to use falvoar with 0 root_gb
12:47:17 sean-k-mooney we could add one for BFV with flavors that are not 0
12:47:38 sean-k-mooney and then you could configure that to @ or a specific rule other then member
12:48:12 sean-k-mooney i dont recally if '@' is the sentenil for no one or everyoen but we have sental values for both

Earlier   Later