| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-23 | |||
| 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 | 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 | |
| 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! | |
| 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 | bauzas | then there is no way for Nova to introspect that VM | |
| 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: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 | sean-k-mooney | it woudl be incorrect for nova to do so in this case | |
| 18:01:37 | bauzas | my proposal was to make it enforced by Glance, provided the operator was wanting it | |
| 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. | |
| 11:23:36 | cardoe | Okay. This will be the third PTG I’ve spoken about the spec. | |
| 13:13:55 | opendevreview | Bence Romsics proposed openstack/nova master: Functional reproducer for #2051685: before fix https://review.opendev.org/c/openstack/nova/+/977331 | |
| 13:13:55 | opendevreview | Bence Romsics proposed openstack/nova master: Suppress error in cleanup of pre live migration https://review.opendev.org/c/openstack/nova/+/982085 | |
| 13:13:56 | opendevreview | Bence Romsics proposed openstack/nova master: Functional reproducer for #2051685: after fix https://review.opendev.org/c/openstack/nova/+/982086 | |
| 15:30:34 | bauzas | eventlet meeting or not ? | |
| 15:30:46 | bauzas | eventlet-removal meeting or not ? | |
| 16:04:53 | zigo | FYI, I was able to have a Gazpacho VM to ping for a few seconds, after reverting a patch in glance-store, and before neutron-dynamic-routing starts crashing on me. :) | |
| 16:05:53 | gibi | zigo: that is progress :) | |
| 16:14:26 | zigo | gibi: It looks like neutron-dynamic-routing or os-ken is broken (one of them) as my BGP session with the switch fails, and never comes back. But otherwise, the rest of OpenStack looks like working ! :P | |
| 16:15:45 | gibi | cool | |
| 16:31:20 | elodilles | Uggla: just a note, that i haven't created a nova RC2 patch as there're only doc change fixes on stable/2026.1 | |
| 16:31:41 | Uggla | elodilles ok | |
| 16:36:39 | Uggla | sean-k-mooney, if you have time, could you make a first pass review of 981557: Reproduce bug #2108974: keypairs lost during cross-cell resize | https://review.opendev.org/c/openstack/nova/+/981557 and 981558: Fix keypairs lost during cross-cell resize | https://review.opendev.org/c/openstack/nova/+/981558 | |
| 16:45:49 | Uggla | gibi, I know you are busy, there is no hurry. But if you can have https://review.opendev.org/c/openstack/nova/+/946945/2 and https://review.opendev.org/c/openstack/nova/+/970337/5 on your re view list that will be great ! | |
| 17:33:11 | clif | o/ | |
| 17:33:53 | JayF | sean-k-mooney: clif is a developer from GR-OSS, I've asked him to help review+cleanup your ironic speedup patches | |
| 17:34:06 | JayF | sean-k-mooney: you'll be better off with clif than me for that kinda stuff; he's more developer coded (to my ops-coded nature) | |
| 17:34:20 | sean-k-mooney | cool | |
| 17:34:33 | sean-k-mooney | clif: o/ | |
| 17:35:03 | cardoe | sean-k-mooney: I've passed https://bugs.launchpad.net/ironic/+bug/2076265 back to Nova. I've left Ironic on it but Nova has to make a change first. | |
| 17:35:06 | clif | nice to meet you, hopefully I can help some of these over the line at least | |
| 17:36:16 | sean-k-mooney | clif: so as i said in the last irc meeting its easy to make things go fast if correctness is not a requirement so that actully goign to part fo the challnge here making sure that these optmistaion are both valid and correct | |
| 17:36:37 | clif | fair enough | |
| 17:37:06 | clif | I also prefer valid and correct | |
| 17:37:14 | clif | fast and incorrect is not very valuable imo | |
| 17:37:15 | JayF | how fast we talkin'? /s | |
| 17:37:46 | sean-k-mooney | JayF: so i think 2 of the 4 optimistiaon are likely correct and of high value | |
| 17:37:50 | sean-k-mooney | the other 2 im unsure | |
| 17:38:07 | sean-k-mooney | so using the threadpool to process nodes in paralle and the deepcopy optimisation | |
| 17:38:38 | sean-k-mooney | but i would love if we coudl create a devstack with the fake ironic driver and try and replciate this in a more real env to see if they actullly help | |
| 17:38:53 | sean-k-mooney | i.e. to make 100% sure that its not an artifcat of the simulator | |
| 17:39:02 | sean-k-mooney | i dont think they are but that still an open | |
| 17:39:46 | sean-k-mooney | for the start up case we dont even really need a full ironic just enouch to hae the api +db so we can add the nodes that nova cna then discover/enmerate | |