| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-23 | |||
| 17:02:10 | Uggla | thanks for joining this meeting. Have a nice day/evening and see you next week. | |
| 17:02:16 | gibi | o/ | |
| 17:02:17 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.log.html | |
| 17:02:17 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.txt | |
| 17:02:17 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.html | |
| 17:02:17 | opendevmeet | Meeting ended Mon Mar 23 17:02:17 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:02:17 | Uggla | #endmeeting | |
| 17:02:24 | lajoskatona | o/ | |
| 17:02:24 | elodilles | same to you, thanks o/ | |
| 18:27:17 | sean-k-mooney | melwitt: thanks for taking a look at https://review.opendev.org/c/openstack/nova/+/975872/5 | |
| 18:28:01 | sean-k-mooney | melwitt: gibi do you thinks we could try and get the repoducer patch merged in the next few days https://review.opendev.org/c/openstack/nova/+/975859/4 while we dicuss the fix in https://review.opendev.org/c/openstack/nova/+/975872 | |
| 18:29:01 | sean-k-mooney | it woudl be nice to make some progress on this again. im hoping to complete that bug work in the next week or two | |
| 18:29:23 | melwitt | sean-k-mooney: ok yeah let me focus on that one then, I had started with the fix (obviously) | |
| 18:29:25 | sean-k-mooney | mainly to avoid having to load context on this over and over again | |
| 18:29:58 | sean-k-mooney | melwitt: ill definally look into your feedback on teh fix too | |
| 18:30:10 | sean-k-mooney | just want to see if we can make incremental progress | |
| 18:31:02 | gibi | sean-k-mooney: I don't immediately have capacity for that patch. Please ping me in couple of days | |
| 18:31:16 | melwitt | sean-k-mooney: sure. thanks for letting me know | |
| 18:31:21 | sean-k-mooney | melwitt: since i started wroking on this i have had time to look at the cybrog quota code and foudn its entrily non fucntional https://bugs.launchpad.net/openstack-cyborg/+bug/2143943 | |
| 18:31:40 | sean-k-mooney | gibi: ack will do | |
| 18:32:04 | melwitt | sean-k-mooney: wow that's wild | |
| 18:32:43 | sean-k-mooney | i have a writeups attached https://launchpadlibrarian.net/851194002/quota-system.md but tldr is the safolding for qutas was built in the v1 api but never ported to v2 | |
| 18:33:26 | sean-k-mooney | at this point i think im just oging to rip it out since it does not work and if we need to have native supprot in cybrog indepent of th enova fix go staight to unified limits | |
| 18:35:01 | melwitt | yeah I think that's probably the best move to just go straight to unified limits | |
| 18:35:27 | melwitt | if fixing the current thing is not trivial | |
| 18:35:52 | sean-k-mooney | well its worked for 10 months and has been broken since 2019 | |
| 18:36:36 | sean-k-mooney | so its not so much how hard is fixing it its is it worth addign a seperate quota api to cyborg at all at this point if we can just use unified limits | |
| 18:36:54 | sean-k-mooney | the entiretly of the v1 api was deleted years ago and it never existed in v2 | |
| 18:36:55 | dansmith | unified limits is easy that way.. saves a lot of api effort | |
| 18:37:18 | melwitt | sean-k-mooney: adding a separate API = not trivial :) so yeah | |
| 18:37:57 | sean-k-mooney | in cybrog qutoa was also only configurable via config before when it did work so there is also no prior art to revive | |
| 18:38:16 | dansmith | that's like glance | |
| 18:38:33 | dansmith | like glance _was_ before unified limits, I should say | |
| 18:38:42 | sean-k-mooney | ack | |
| 18:39:15 | dansmith | even if you had prior art, unified limits instantly makes you more modern and compatible with the way the other projects are going, IMHO, so that's a reason right there | |
| 18:40:29 | sean-k-mooney | right now im not fucosing on cybrog as a standalone service "without nova" so if we fix the enfocement on the nova side then that closes the gap although at some point i shoudl add quta checks indepenet of nova spawn/resize code before we add attach/detach supprot | |
| 18:41:44 | sean-k-mooney | anyway out of scope of nova but this will eventually get doen after the other higher priorty items | |
| 18:42:57 | sean-k-mooney | ARQ binding is when a resouce is actully assigne dto an instnace so that is where we should be checking to prevent over quota usage longterm. | |
| 18:43:38 | sean-k-mooney | i.e form parallel nova instance cretes | |
| 20:06:56 | opendevreview | Merged openstack/nova master: Move py312-threading to py313 https://review.opendev.org/c/openstack/nova/+/980458 | |
| #openstack-nova - 2026-03-24 | |||
| 06:59:17 | gokhan | you typically manage per cell to keep things stable and limit the blast radius? I'd love to hear your experiences on whether a single-cell setup can actually handle 1,000 nodes with the right tuning, or if I should definitely start splitting things up now. Thanks a lot for any tips! | |
| 06:59:17 | gokhan | Hi everyone, I’m working on designing a large-scale architecture and could use some advice from the community. So far, I’ve been running about 50-100 hypervisors with 3 controllers without any issues, but I'm now planning to scale up to 1,000 nodes and I'm wondering what the best path forward is. At what point does Cells v2 become a 'must-have' rather than just an option? For those of you running massive setups, how many compute nodes do | |
| 08:13:58 | gibi | gokhan: I think 1000 node in a single cell is a huge strech. Might work if you have a fairly static workload. I think our non official recommendation is to start considering cells around 200 nodes | |
| 08:17:26 | gibi | gokhan: if you search around the net you will find reports from large scale openstack deployers, like CERN, about their size and tuning. For example https://superuser.openinfra.org/articles/large-scale-openstack-operators-tricks-and-tools-openinfra-live-recap/ or https://techblog.web.cern.ch/techblog/ | |
| 08:53:22 | gokhan | thanks gibi for your insights :) | |
| 08:55:46 | gibi | gokhan: also take the approach to scale gradually if you can, and measure the scale. If you see a bottleneck in certain operations then we can help suggesting tunings for it | |
| 08:56:09 | gibi | unfortunately there is no one single good answer for scale | |
| 09:07:51 | gokhan | thanks gibi, we will start with about 100 nodes per cell . | |
| 09:19:20 | opendevreview | Merged openstack/nova master: docs: mention q35 machine type for UEFI guests https://review.opendev.org/c/openstack/nova/+/981413 | |
| 15:38:33 | yessou-sami | Hi everyone, i was wondering if has anyone done an analysis about how much is safe enabling hw_qemu_guest_agent on openstack to enable guest agents to be in contact with the hypervisor? | |
| 15:59:05 | sean-k-mooney | that now quite how that works | |
| 15:59:38 | sean-k-mooney | hw_qemu_guest_agent when you enable hw_qemu_guest_agent it provide a channel form the hsot to allow the host to interact with an agent in teh guest | |
| 15:59:49 | sean-k-mooney | but it does not provide a way for the guest to interact with the hypervior | |
| 15:59:59 | sean-k-mooney | at least not by default | |
| 16:00:49 | sean-k-mooney | hw_qemu_guest_agent is generally consider safe unless you are plannign to develop a host agent that will interact with it or do some other custom integration | |
| 16:59:12 | gibi | also settinng hw_qemu_guest_agent alone is not enough, the image needs to have the agent installed. Nova neiter checks for it nor installs it into the guest. | |
| 17:00:13 | bauzas | fun that I answered the same question earlier today somewhere else | |
| 17:00:42 | bauzas | if people want to ensure that GA is installed if users set the GA property, then they have to talk to Glance, not us | |
| 17:06:29 | cardoe | hello all. Still hoping to see https://review.opendev.org/c/openstack/nova-specs/+/471815 get done. The code is written for a few cycles. As are the tests. The code is deployed for a number of cloud operators as well. | |
| 17:29:33 | sean-k-mooney | gibi: yes and for the actual usful featre i.e. quiesing the guest disk on snapshot i think you need to set a second extra spec too | |
| 17:30:36 | sean-k-mooney | os_require_quiesce | |
| 17:30:50 | sean-k-mooney | although in thory an operator can use teh qemu geust agent for other thing | |
| 17:31:17 | sean-k-mooney | i belive rackspace used to use it to configure soem thign by defualt in there cloud like dhcp/dns ectra | |
| 18:00:22 | sean-k-mooney | bauzas: well hw_qemu_guest_agent isnt strictly saying it is installed in teh current image. its saying i want to use the guest agent. for reason i might chosse to install it after the fact with ansible or cloud init in the image | |
| 18:00:32 | sean-k-mooney | *in the vm rather then in the image | |
| 18:00:56 | sean-k-mooney | but ya all that image proprly does is ensure the qemu channel for the guest agent is providsioned in qemu | |
| 18:00:56 | bauzas | then there is no way for Nova to introspect that VM | |
| 18:01:10 | sean-k-mooney | bauzas: correct that is out of scope fo nova | |
| 18:01:20 | bauzas | at least I don't want to have Nova introspecting the guest :) | |
| 18:01:28 | sean-k-mooney | nor do i | |
| 18:01:37 | bauzas | my proposal was to make it enforced by Glance, provided the operator was wanting it | |
| 18:01:37 | sean-k-mooney | it woudl be incorrect for nova to do so in this case | |
| 18:01:50 | bauzas | but that's a Glance discussion | |
| 18:01:52 | sean-k-mooney | oh no i dont think galnce shoudl enforce it either | |
| 18:02:06 | sean-k-mooney | that to me woudl be a breakign chagne requrieign at least a config option | |
| 18:02:24 | sean-k-mooney | as i said this image peroperlty is for requesting the guest agent channel to be provisioned | |
| 18:02:35 | sean-k-mooney | its not declearing that the image has it installed | |
| 18:02:38 | sean-k-mooney | those are two very diffent things | |
| 18:02:41 | bauzas | surely, I'm just saying that the service that has the responsibility for introspecting the image is Glance as of today | |
| 18:03:02 | sean-k-mooney | sure but im saying that the image proprty does not state that its installed | |
| 18:03:09 | sean-k-mooney | that not what its for | |
| 18:03:17 | bauzas | sean-k-mooney: yup yup, but AFAICU, the request was to have GA be default | |
| 18:03:34 | bauzas | since public clouds operators don't trust their users | |
| 18:03:36 | sean-k-mooney | oh thats an entirly diffent converation | |
| 18:03:39 | sean-k-mooney | we coudl do that | |
| 18:04:01 | sean-k-mooney | or make it configurable via the flavor so admin can opt in | |
| 18:04:14 | sean-k-mooney | but that very diffent then introspecting the image | |
| 18:27:45 | gmaan | Gibi: Bauzas: Not sure if you got time to check this change (running graceful shutdown running on both mode), but it will be good to do it before any breaking change. https://review.opendev.org/c/openstack/nova/+/978292 | |
| 18:27:54 | gmaan | gibi: ^^ | |
| 18:30:40 | gibi | gmaan: +2, thanks | |
| 18:30:45 | gmaan | thanks | |
| 18:36:24 | opendevreview | Ghanshyam Maan proposed openstack/nova stable/2026.1: DNM: test grenade job https://review.opendev.org/c/openstack/nova/+/981980 | |
| 18:39:24 | opendevreview | Ghanshyam Maan proposed openstack/nova stable/2025.2: DNM: test grenade job https://review.opendev.org/c/openstack/nova/+/981982 | |
| 20:53:14 | JayF | Uggla: I don't see OpenStack Nova with a slide in OpenInfra Live Gazpacho; is nova being repped in that at all? Y'all probably should have someone there :| | |
| 20:58:53 | sean-k-mooney | i tought someone was going to attend but i have not really been invoved | |
| 22:42:27 | Uggla | JayF, I have just answered that I will cover Nova highlights. Thanks for the reminder. | |
| 22:43:46 | JayF | awesome, thanks. It didn't look like many projects had opted in so I'm glad to get more | |
| #openstack-nova - 2026-03-25 | |||
| 02:38:46 | cardoe | Uggla: just wanted to follow up on https://review.opendev.org/c/openstack/nova-specs/+/471815 happy to come to the next nova meeting to discuss. | |
| 10:48:11 | Uggla | cardoe, I suggest you to enter a topic in https://etherpad.opendev.org/p/nova-2026.2-ptg, then I will find a slot to discuss it at the PTG. | |
| 10:50:56 | Uggla | cardoe, it will also allow other cores to read the spec upfront and load context for the PTG. | |