October 2025 - openstack-discuss - lists.openstack.org

[tacker][ptg] 2025.10 vPTG Planning
by Yasufumi Ogawa 27 Oct '25

27 Oct '25

Hi tacker team, As we discussed in the previous meeting, we'll have two days sessions for the vPTG. I've fixed time slots for our vPTG session[1] and setup the etherpad[2]. Please add your items on the etherpad if you have any proposal. - 29th Oct. 8am-10am UTC (5pm-7pm JST/KST) - 31th Oct. 8am-10am UTC (5pm-7pm JST/KST) [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2025-ptg-tacker Regards, Yasufumi

1 0

[kolla][kolla-ansible][kayobe] Bifrost usage poll
by William Szumski 27 Oct '25

27 Oct '25

Hi all, I was just trying to get an idea for the number of operators relying on the Bifrost support in Kolla-Ansible as it was recently deprecated in Kolla[1]. We are planning the next steps for its replacement, and are not sure if it is is only Kayobe users that would be affected. If you you are using Bifrost and not using Kayobe, I would appreciate if you could reply to this message. We will also be discussing Bifrost as the first topic in the Kayobe/Kolla PTG session on Wednesday 19th November at 13:00 UTC and would encourage you to come along and discuss its future. Although, nominally it is the Kayobe session, we've made the first topic on the agenda so that you easily drop out if you aren't interested in the rest of the discussion. [1] https://review.opendev.org/c/openstack/kolla-ansible/+/945501 Thanks, Will

1 1

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Jean-Philippe Jung 27 Oct '25

27 Oct '25

Hi, I am the OpenStack Security Product Manager at Red Hat. I also support Post Quantum Cryptography in OpenStack and k8s (well, OpenShift for us), and I cover some areas of confidential computing. I see one existential risk to OpenStack in the near future: support for post-quantum cryptography (PQC) [0] Based on my latest discussion with industry experts, I expect that around 2029 (likely) or 2030 (at best), there would be powerful enough Q-Computers to break traditional cryptography. Meaning we have to prepare OpenStack to support post-quantum crypto (ML-KEM urgently, ML-DSA as soon as possible) in the upstream code. As we also need to provide time for operators/customers to implement the "fixed" code, we are in early 2028 territory to achieve sufficient PQC coverage in OpenStack upstream. This would give OpenStack users time to implement this code. Time is running out; we’re already almost in 2026! A point to keep in mind is that the initial PQC algorithms might fall short and be replaced in the future. Thus, this PQC support exercise should also be a “cryptographic agility” exercise: we should have a few libraries we know how to call, and if a new crypto algorithm comes out, it should be easy to enable it in the code. I used AI engines to have a look at the OpenStack upstream code (not all projects, but a chunk of the most commonly used), and I came back with 17 different cryptographic modules, 7 of which received no commits in over 2 years. It might be directly in the code or in pulled dependencies. The first step to solving a problem is recognizing we have one. We have a problem. I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five). Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams: Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization. What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration? I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face. Looking forward to hearing from you and collaborating upstream to improve OpenStack. Regards, Jean-Philippe (JP) Jung jjung(a)redhat.com irc: jjung [0] Quantum what? Quantum computers will break current encryption algorithms like RSA and elliptic curve cryptography using Shor's algorithm, exposing all data encrypted today. Adversaries are already harvesting encrypted data to decrypt later once quantum computers mature. OpenStack powers critical cloud infrastructure globally. Deploying post-quantum cryptography (PQC) upstream is essential because downstream distributions and deployments inherit these security foundations. Without upstream PQC integration, the entire OpenStack ecosystem remains vulnerable, putting sensitive workloads, government systems, and enterprise data at risk. The migration takes years, so implementing PQC now in the codebase is operationally necessary, not optional. [1] https://wiki.openstack.org/wiki/Post_quantum_openstack

7 12

[Neutron] Bug deputy Oct 20-27
by Jakub Libosvar 27 Oct '25

27 Oct '25

Hi, I was the bug deputy last week. There was one bug reported by Rodolfo that was set to high priority but has no assignee. Here is the summary. High ---- * [OVN] Error when using tunnelled external networks and multihoming GW routers https://bugs.launchpad.net/neutron/+bug/2129750 Needs assignee Medium ------ * unittest test_ovsdb_monitor overwrites ovs.Stream module variables https://bugs.launchpad.net/neutron/+bug/2129284 Assigned to myself Patch proposed https://review.opendev.org/c/openstack/neutron/+/964493 * VPNaaS endpoint group creating with non-unique endpoints takes a long time to fail https://bugs.launchpad.net/neutron/+bug/2129681 Assigned to Sebastian Patch proposed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/964686 Low --- * [OVN] Avoid creating session less admin context in the OVN client methods https://bugs.launchpad.net/neutron/+bug/2129674 Assigned to Rodolfo Patches proposed: - https://review.opendev.org/c/openstack/neutron/+/964788 - https://review.opendev.org/c/openstack/neutron/+/964679 Incomplete ---------- * Mixed port configuration native and tagged traffic whould not pass native vlan to trunk list https://bugs.launchpad.net/neutron/+bug/2129533 Needs an assignee to follow up with the reporter

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and PTG Agenda (2026.1/R-22)
by Goutham Pacha Ravi 27 Oct '25

27 Oct '25

Hello Stackers, Welcome to the Project Teams Gathering week [1][2]. Throughout the week, there are a lot of discussions planned over multiple tracks. The OpenStack Technical Committee will be meeting virtually as well as a part of this, and the meetings are between 1600 UTC and 1800 UTC on Tuesday, October 28, 2025, and between 1600 UTC and 1800 UTC on Friday, October 31, 2025. At 1600 UTC on Tuesday, October 28, 2025, we'll be meeting with maintainers across all project teams. If you are a PTL, a DPL liaison, or a core reviewer, please join us so we can have a productive discussion on impactful cross-project work that needs to happen in the 2026.1 "Gazpacho" release. The rest of the week is action-packed as well. I'd recommend that you consult the discussion Etherpads and stay plugged in via the #openinfra-events IRC channel on OFTC. If you'd like to propose new topics on the TC's PTG etherpad [3], please add them at the end of the pad under "Parking Lot," and I'll try to get them scheduled. === Weekly Meeting === The OpenStack Technical Committee held its last weekly IRC meeting on October 21, 2025 [4]. We confirmed the inactivity of the Vitrage and Venus project teams, noting they could face retirement before the M-2 milestone of the 2026.2 release if activity doesn't resume. A significant portion of the discussion focused on the long-standing inactive status of Monasca, with most present TC members strongly favoring proceeding with its retirement. There was also a preference for keeping it inactive for another cycle due to awareness of external interest in reviving it, though this interest has yet to materialize into active contributions. The consensus was to seek more votes on the retirement patch and close this out after the Project Teams Gathering. Other updates included the Skyline project's core reviewer self-nomination [5], where the Project Team Lead (PTL) welcomed the candidate, but the TC agreed that adding the person to the core reviewer group was premature given their lack of review history. Patches in the CI to reflect Gazpacho release runtime updates have merged [6], with only a patch for Grenade struggling with CI instability. Gate health is generally stable, though the recent outages of docker.io and quay.io highlighted a need for more autonomy in container image hosting. Finally, the committee discussed topics for the upcoming Project Team Gathering (PTG), including the need to address the use of unmaintained crypto libraries across OpenStack projects. The TC will not be meeting over IRC this week in lieu of the PTG. Weekly IRC meetings will resume next on November 4, 2025. === Governance Proposals === ==== Merged ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 ==== Open For Review ==== - Propose jlarriba to Telemetry PTL | https://review.opendev.org/c/openstack/governance/+/964516 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ - 2025-11-04: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-11-15: Celebrating 15 years of OpenStack, Montréal - 2025-11-15: KCD + OpenInfra Days, Hangzhou: https://sessionize.com/kcd-hangzhou-and-oicd-2025/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] 2026.1 PTG Etherpads: https://ptg.opendev.org/etherpads.html [3] OpenStack TC 2026.1 PTG Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-os-tc [4] TC Meeting IRC Log, Oct 21, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-10-21-08.00.html [5] 2026.1 runtime update: https://review.opendev.org/q/hashtag:%222026-1-runtime-update%22+(status:op… [6] Skyline core contributor discussion: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 26 Oct '25

26 Oct '25

Hi team, Sorry for the late notice. Due to the vPTG, I'd like cancel the IRC meeting this week. Yasufumi

1 0

Keystone+Keycloak OIDC 403 Error on openstack CLI test
by Tyler Wilson 25 Oct '25

25 Oct '25

Hello All, I'm trying to get a test idp setup going via this document: https://docs.openstack.org/kolla-ansible/latest/contributor/setup-identity-… and everything seems to be configured correctly however I am getting a 403 when I try to use the openstack CLI to test. # openstack token issue You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-be79246b-ccc1-4fbd-ba3f-fa98b9cae7ba) # openstack user show customer01 You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-4e385968-796e-44a0-8003-351188c202ba) In the keystone log I see a traceback with handle_unscoped_token and apply_mapping_filter (full output here: https://pastebin.com/xZ2qeCPW ) so maybe I'm missing something with permissions? I have the attribute mapping exactly as it is in the documentation, and im getting this when replicate the POST to userinfo with the bearer token; {"sub":"$UUID","email_verified":true,"name":"CustomerFirst CustomerLast","preferred_username":"customer01","given_name":"CustomerFirst","openstack-default-project":"customers","openstack-user-domain":"cloud.ld","family_name":"CustomerLast","email":"customer01(a)example.com"} I also checked keycloak and the user event log shows green authentications. Both domain and project exist in identity as well # openstack domain list | grep cloud.ld | $UUID | cloud.ld | True | | # openstack project list | grep customers | $UUID | customers | I'm using these exports for the client export OS_AUTH_URL=http://$KEYSTONE_IP:5000/v3 export OS_PROJECT_NAME="customers" export OS_PROJECT_DOMAIN_NAME="cloud.ld" export OS_USERNAME="customer01" export OS_PASSWORD="$USER_PASSWORD" export OS_INTERFACE=public export OS_IDENTITY_API_VERSION=3 export OS_CACERT=/etc/ssl/certs/ca-certificates.crt export OS_AUTH_TYPE=v3oidcpassword export OS_CLIENT_ID=Keystone export OS_CLIENT_SECRET=$SECRET_ALTHOUGH_DOESNT_MATTER export OS_IDENTITY_PROVIDER=cloud.ld export OS_PROTOCOL=openid export OS_ACCESS_TOKEN_ENDPOINT=https://$KEYCLOAK_IP:8443/realms/cloud.ld/protocol/openid-connect/token Is there anything I might be missing here? Thanks for any help!

3 3

[PTG][neutron] Neutron schedule
by Brian Haley 24 Oct '25

24 Oct '25

Hi Neutrinos and stackers, I have added a rough schedule to our etherpad [0] for next week's vPTG meetings, please check it and make sure the times work if you had added a topic. Based on my estimates we will only meet on Tuesday and Wednesday and not have anything on Thursday, subject to change based on how long discussions take. There are cross-projects with Ironic and Nova on Wednesday. Room info is all at [1]. See you then, -Brian [0] https://etherpad.opendev.org/p/oct2025-ptg-neutron [1] https://ptg.opendev.org/ptg.html

1 0

[PTG][Horizon][outreachy][all] A story of OpenInfra User Group Kenya
by Tatiana Ovchinnikova 24 Oct '25

24 Oct '25

Hello all, Horizon is proudly hosting the PTG session of our former outreachy intern, Agnes Nduta, now the main organizer of OpenInfra User Group Kenya. Please join us in icehouse room on Tuesday, October 28, 2025 @ 16:30 UTC - 17:00 UTC Horizon etherpad link: https://etherpad.opendev.org/p/horizon-gazpacho-ptg With kind regards, Tatiana

1 0

[PTG][Horizon][Manila][Plugins] Upcoming PTG session on integration tests for Horizon and plugins
by Tatiana Ovchinnikova 24 Oct '25

24 Oct '25

Hello all, Horizon team is hosting a session on integration tests for Horizon in general and for Manila UI plugin in particular. Manila is the first plugin we are covering, so other Horizon plugins could take it as an example and get some ideas on how they could use some general fixtures implemented in Horizon. The session is scheduled on Tuesday 28th at 16:00 UTC, icehouse room. Here is the etherpad link: https://etherpad.opendev.org/p/horizon-gazpacho-ptg Feel free to join us! With kind regards, Tatiana

2 2

[cinder] PTG reminder and schedule
by Jon Bernard 24 Oct '25

24 Oct '25

Hello all, We covered the schedule [1] in this week's meeting but I wanted to post it here for reference. We will be meeting Tuesday, Wednesday, Thursday, and Friday of this week starting at 14:00 UTC. We technically have 4 hours each day to cover topics. Historically we have not needed all of that time, so I expect there will be some variability in end time. Two notable things to keep in mind: * We begin on Tuesday, not Monday - though there are some other sessions that day you may find interesting. See [2] for the full schedule * We have 4 cross team sessions with Eventlet, Nova, Glance, and Ironic. Keep those time slots in mind of those topics are of interest to you. Hope to see you all there! [1] https://etherpad.opendev.org/p/cinder-gazpacho-ptg [2] https://ptg.opendev.org/ptg.html -- Jon

1 0

[ptg][nova][ironic][cinder]cross-project sessions
by Iury Gregory 24 Oct '25

24 Oct '25

Hello nova and cinder folks, In the preparation for the upcoming PTG, we have some topics that we would like to discuss - *[ironic][nova] *Graphical Console follow-up https://etherpad.opendev.org/p/ironic-ptg-2026.1#L137 - *[ironic][nova][cinder] *NVMe over TCP https://etherpad.opendev.org/p/ironic-ptg-2026.1#L75 Next week we will be booking some time slots for ironic, feel free to reachout to us on #openstack-ironic with the time slots that would work for all teams. Best regards, -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 3

[PTG][ironic][neutron] cross-project session
by Iury Gregory 24 Oct '25

24 Oct '25

Hello neutron folks, In the preparation for the upcoming PTG, we would like to have a cross-project section to discuss about the VXLAN attachments [1] , we can book a slot that would work for the people that are interested in the topic. Next week we will be booking some time slots for ironic, feel free to reachout to us on #openstack-ironic with the time slots that would work for the neutron team. [1] https://etherpad.opendev.org/p/ironic-ptg-2026.1#L97 Best regards, -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 3

[PTG][ironic] Ironic Schedule
by Iury Gregory 24 Oct '25

24 Oct '25

Hello ironicers and stackers. We have our schedule for the PTG: =============================== Monday 27 13:00 UTC - 17:00 UTC =============================== - Flamingo Retrospective ~ 30min - Should we move back to a PTL model as a central driver standpoint, or something else. ~ 30min - Improving review process ~ 30min - In-project SIG to focus on aspects where operators are demanding a greater depth to Ironic's capabilities ~ 15min - AZ modeling in our Docs ~15min - Docs cleanup ~15min - Retrie irmc ~ 15min - Abort friendliness ~ 30min - Emergency Bulk Operations ~ 30 min - Diskimage-builder 20min ================================= Thuesday 28 13:00 UTC - 17:00 UTC ================================= - Post Eventlet world ~ 1h30min - Deferred tasks ~ 20min - Scaling Ironic Prometheus Exporter and generally hardware metrics ~ 20min - Async/await in ironic ~ 50mim - (JayF) More flexibility in sushy/redfish interfaces ~ 1h - Let's stop maintaining sushy as a separate project? ~ 30min - Redfish Virtual Media via NFS and SMB shares ~ 20min - Agent Virtual Media Image sizes ~ 20min ================================== Wednesday 29 13:00 UTC - 17:00 UTC ================================== - Snapshooting ~ 30min - Toggling port behavior from Network to Storage and back ~ 30min - Status of Trait Based Networking 20min # 14:30 - 15:30 - VXLAN attachements | Cross-Project with Neutron ~ 1h # 15:30 - 17:00 - Graphical Console follow-up | Cross-Project with Nova ~ 30min - As a infrastucture operator, I want to boot the machines from NVMe-over-TCP (over Ethernet) | Cross-Project with Cinder/Nova ~ 1h ================================== Thursday 30 13:00 UTC - 17:00 UTC ================================== - Should we keep PreP partition support in IPA 15min - Handling fast-track support w/ standalone networking ~ 45min - DCIM Integration ~ 20min - CentOS usage -20min - DHCP-Less Revisit 30min - Brainstorming/Revisiting Concurrent Action Limit? 25min - Has anyone looked into making project specific resource scheduling mapping? 25min - Metal3 25min Best regards, -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 1

[nova]Live-resize feature
by Nguyễn Hữu Khôi 24 Oct '25

24 Oct '25

Hello, This topic looks like it will be asked many times but I am curious why it won't be implemented. Does it have impacts on the system? I see that will be an useful feature. Nguyen Huu Khoi

3 6

[manila] PTG schedule + cross project sessions with Nova and Horizon
by Carlos Silva 23 Oct '25

23 Oct '25

Hello zorillas and interested stackers, I would like to share with you the schedule for next week's PTG [1] which is also the official PTG etherpad. In case you would like to request schedule changes, please let me know as soon as possible. We will also have two cross project sessions: Cross project with Horizon - Manila UI testing - Icehouse room, Tuesday, 15:00 UTC (to be confirmed) Coss project with Nova - All things VirtioFS - Grizzly room, Wednesday 17:00 UTC [1] https://etherpad.opendev.org/p/gazpacho-ptg-manila Looking forward to a productive PTG! Regards, carloss

1 0

[osa][kolla][openstack-helm][puppet] Cross-deployment-projects PTG session
by Michał Nasiadka 23 Oct '25

23 Oct '25

Hello, Me and Dmitriy (noonedeadpunk) have an idea of making a cross-deployment-projects PTG session - where we could discuss some common problems and topics. I’ve created an etherpad [1] for collaboration purposes. We’re reaching out to OpenStack-Helm and Puppet projects if they would be interested in joining and discussing things we could improve together in OpenStack ecosystem. Please also put possible timeslots from your side in the etherpad. [1]: https://etherpad.opendev.org/p/oct2025-ptg-cross-deploy Cheers, Michal

1 0

[nova] Persistent PXE boot for VMs
by Eugen Block 23 Oct '25

23 Oct '25

Good morning, we have the requirement to let a subset of VMs always boot in PXE mode. They're managed by a Uyuni server that controls whether a VM has to be (re)installed or if it should boot from local disk. I've been searching and testing, but to no avail yet, except for modifying the xml file which will not persist [0]. Is there a known history why this isn't possible (yet) or has this already been discussed and the decision was to not implement such a feature? We're thinking about implementing a solution for us, but would be also interested if a PR would have a chance to be accepted. If anyone has some insights/ideas/recommendations, I'd appreciate it. Thanks! Eugen [0] https://blog.dachary.org/2012/10/08/network-boot-an-openstack-instance/

4 13

[telemetry][TC] Stepping down from Telemetry PTL
by Matthias Runge 22 Oct '25

22 Oct '25

Hi there, due to other time commitments, I would need to step down from Telemetry PTL and proposed Juan Larriba -- the previous PTL -- to take over[1]. I won't be far, but I also believe the project is in better hands of a person who is nearer to the code these days. Matthias [1] https://review.opendev.org/c/openstack/governance/+/964516

2 1

[oslo][messaging] Container fix of QManager breaks it for containers
by Dmitriy Rabotyagov 22 Oct '25

22 Oct '25

Hey folks, I wanted to raise attention to a relatively old issue, which has had a patch around since January [1]. Basically a regression [2] was introduced and backported to 2024.1 as part of an attempt to fix QManager execution in containers. However, it does not account for the possibility of os.getpgrp() returning 0 in some edge cases, which makes, for instance, impossible to sync database for Nova during upgrades, if QManager is used. Thus I'm asking to kindly review the [1] as it appears to be a blocker for some upgrades involving affected versions of oslo.messaging. I have not spotted this patch right away, so I proposed an alternative [3], but I'm happy to abandon it in favor of [1]. Thanks in advance for upcoming reviews :) [1] https://review.opendev.org/c/openstack/oslo.messaging/+/939540 [2] https://review.opendev.org/c/openstack/oslo.messaging/+/928034 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/958528

2 3

[nova] [nova-scheduler] Performance Issue with CPU Pinning Scheduling and Duplicate IPs
by İzzettin Erdem 22 Oct '25

22 Oct '25

Hi, In our environment (Kolla-Ansible Ussuri, 1200+ hypervisors), we are experiencing performance issues during bulk VM deployments. When launching around 100 VMs, the operation takes approximately *15 minutes*. During this time, the *nova-scheduler* spends over *15 minutes calculating available pinned CPUs*. However, in our Yoga production deployment, the same operation is about *10 times faster* — around *1–2 minutes* for 100 VMs. Additionally, after the 100 VMs are created, we have observed that some instances could not be created and some of the rest receive *multiple (2–3) IP addresses* from Neutron instead of one. Our nova services are running in a *NUMA-aware, CPU-pinning* configuration, and other settings are almost identical to the default configuration. Below is an excerpt from the nova-scheduler logs during VM creation (this message is repeated thousands of times within 15 minutes): Computed NUMA topology CPU pinning: usable pCPUs: [[26, 90], [89, 25], [24, 88], [27, 91], [29, 93], [10, 74], [86, 22], [28, 92], [73, 9], [23, 87], [8, 72], [18, 82], [94, 30], [81, 17], [31, 95]], vCPUs mapping: [(0, 26), (1, 90), (2, 89), (3, 25), (4, 24), (5, 88), (6, 27), (7, 91), (8, 29), (9, 93), (10, 10), (11, 74), (12, 86), (13, 22), (14, 28)] Do you have any suggestions on what might be causing: 1. The scheduler to spend so much time calculating pinned CPUs in Yoga, and 2. Some VMs to get multiple IPs from Neutron after creation? Any guidance would be greatly appreciated. Best regards, İzzettin

1 0

[kolla-ansible] [nova] Database connection points to nova cell db
by İzzettin Erdem 22 Oct '25

22 Oct '25

Hi, In Kolla-Ansible deployments, the connection parameter under the [database] section in the nova.conf template points to the *nova_cell* database [1] <https://opendev.org/openstack/kolla-ansible/src/commit/4e3208b16c452d1cf2cd…>. As far as I understand, the *nova_cell* database is primarily used to store failed operations. I was wondering: if we are not using a multi-cell architecture, should the connection instead point directly to the *nova* database rather than *nova_cell*? There was an open bug related to this issue almost a year ago, but it has not received any updates yet [2] <https://bugs.launchpad.net/kolla-ansible/+bug/2088264>. Could you please confirm whether the current configuration is correct? We have deployed OpenStack using the existing configuration and it is currently running in production. If we change the database connection in the running environment, would that cause any issues? Thank you for your time and assistance. Best regards, İzzettin

2 1

[publiccloud-sig] Public Cloud SIG meeting d.d. 22 October
by Kees Meijs | Nefos 22 Oct '25

22 Oct '25

Hello Stackers, For whom I've met at the summit: it was great to be there and meet you all! Tomorrow (that's 22 October) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 07:00 hrs UTC (09:00 hrs CEST) and on here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 1

[nova] Memory performance issue while using property "hw:numa_nodes='2'" in flavors
by brijesh.mishra＠five9.com 21 Oct '25

21 Oct '25

Hi Team We have use Kolla ansible for openstack Caracal 2024.1 deployment. Having 2 production sites, we have observer that the Nova scheduler is allocating virtual machines (VMs) only on a single NUMA socket of the compute host. Since the flavor does not include the property hw:numa_nodes='2', vCPUs spread on two NUMA nodes scheduling is not enabled. As a result, all vCPUs and memory for a VM are placed on a single NUMA node, while the other NUMA socket(s) remain underutilized. So we tested this property in our test flavor and found that now scheduler is able to spread vcpu/vm across two numa sockets but performance on memory side is degraded for about 20% to 30%. So we are looking for suggestions on this if there is better way to accommodate more VMs or spread vcpu on two numa socket without having performance issues on memory or cpu side, or something which have less impact? Regards Brijesh

2 1

[Caracal]Optimizing Nova NUMA Scheduling Behavior (Single vs Dual NUMA Socket Allocation)
by Vish Mudemela 21 Oct '25

21 Oct '25

Hi Team, We are using Kolla Ansible for our OpenStack Caracal (2024.1) deployment across two production sites. We have observed that the Nova scheduler is currently allocating virtual machines (VMs) only on a single NUMA socket of the compute host. Since our flavors do not include the property hw:numa_nodes='2', the scheduler places all vCPUs and memory for a VM on a single NUMA node, leaving the other NUMA socket(s) underutilized. In our testing, we added the hw:numa_nodes='2' property to the flavor and confirmed that the scheduler can now distribute vCPUs across both NUMA sockets. However, this configuration led to 20–30% memory performance degradation, likely due to cross-NUMA memory access. We also noticed that once this property is set, the scheduler always attempts to spread vCPUs across two NUMA sockets — even when there are sufficient resources available on a single NUMA node. We are looking for a way to achieve conditional NUMA placement — ideally: - If a single NUMA node has enough capacity, schedule the VM entirely on that node. - Otherwise, allow the scheduler to spread the VM across multiple NUMA nodes. We would appreciate any suggestions or best practices to: Improve NUMA-aware scheduling efficiency,Better utilize both NUMA sockets without significant memory performance penalties, andAvoid forcing cross-NUMA allocation unless necessary. Has anyone in the community implemented or tuned Nova in a way that balances these requirements effectively? Thanks in advance for your insights and recommendations. Thanks

2 1