Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-23
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.
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: Suppress error in cleanup of pre live migration https://review.opendev.org/c/openstack/nova/+/982085
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: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.

Earlier   Later