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

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 08 Dec '25

08 Dec '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 14

[Octavia][Load Balancer][2023.1] Amphora Fails Health Check – “No Route to Host” & Timeout Errors
by Thamanna Farhath 02 Dec '25

02 Dec '25

Hi OpenStack Community, I am currently facing an issue with the Load Balancer (Octavia) service in my OpenStack deployment and would appreciate your guidance or suggestions on how to troubleshoot and resolve it. Environment Details: OpenStack Version: 2023.1 (Antelope) Operating System: Ubuntu 22.04 Octavia Backend: Amphora Network Type: VXLAN Deployment Tool: Kolla Ansible Issue Summary: After creating a Load Balancer, the Amphora instance is successfully launched. However, approximately 18 minutes later, the Load Balancer transitions to an ERROR state. Error Observed: octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id a222527f-8336-4fb1-8e9e-0e3ac6e8d580 to go active timeout. octavia.amphorae.driver_exceptions.exceptions.AmpConnectionRetry: Could not connect to amphora, exception caught: HTTPSConnectionPool(host='192.168.200.247', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError: Failed to establish a new connection: [Errno 113] No route to host) What I’ve Tried: Created a VXLAN-based internal network: openstack subnet create --network octavia-mgmt-net --subnet-range 192.168.200.0/24 octavia-mgmt-subnet openstack router create octavia-router openstack router add subnet octavia-router octavia-mgmt-subnet openstack router set octavia-router --external-gateway <public-network-id> Manually configured OVS interface: ovs-vsctl add-port br-int octavia-mgmt -- set interface octavia-mgmt type=internal ip addr add 192.168.200.1/24 dev octavia-mgmt ip link set octavia-mgmt up Security groups are open (allowing all ingress and egress). Verified OVS bridge setup – interface appears correctly on br-int. Behavior Noticed: Amphora instance gets created but fails to communicate with the controller after a while,so health checks fails. The controller cannot reach the Amphora management IP (192.168.200.x). Logs show heartbeat/connection issues (No route to host, timeouts). Request for Help: I would appreciate any of the following: Suggestions to verify if the management network is properly routed from controller to Amphora. Best practices for setting up the Octavia management network using VXLAN. Troubleshooting steps for verifying health manager connectivity to Amphora. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 3

[tc][tripleo] About os-net-config
by Goutham Pacha Ravi 18 Nov '25

18 Nov '25

Hello Stackers, I am writing to seek clarity regarding recent activity on the PyPI project for os-net-config [1]. As you can tell, "OpenStack" is still listed as the author/maintainer of this package. "os-net-config" was retired early last year along with the rest of the TripleO project within OpenStack's governance [2]. It appears that development has continued outside of OpenStack with the project being forked [3]. There have been releases that were uploaded to PyPi since. A human maintainer was added to PyPi this week. There may be some rationale to continue to maintain this code. Since the project was officially retired from OpenStack, we need to ensure that any renewed activity is properly communicated; and the author/maintainers are properly attributed. For one, "OpenStack" can't be the Author/Maintainer of a project that's not officially under OpenStack Governance. There are references to the OpenStack Documentation Website, TC Badges and IRC/bug tracker links that may now be obsolete and must be removed. This could be confusing to past, current and future users of the project, not to mention the security implications and responsibility attribution on code that's used in systems worldwide. Can the current maintainers please engage with us to make the necessary changes? You can do so here, or chat on #openstack-tc on OFTC. Thanks, Goutham Pacha Ravi [1] https://pypi.org/project/os-net-config [2] https://review.opendev.org/c/openstack/governance/+/905145 [3] https://github.com/os-net-config/os-net-config

4 4

Opensearch Service Update
by Daniel Pawlik 14 Nov '25

14 Nov '25

Hello, We would like to notify you that the Opensearch service [1] would be updated to a newer version on 13 November 2025 at 12:00 PM UTC. This procedure might take a while, depending on the cluster size. During that time, the Opensearch service would not be available. If anyone has any doubts, please reply to the email. Dan [1] - https://opensearch.logs.openstack.org/_dashboards/app/home

2 2

[ops][largescale-sig] Refactoring Ops-related activities - a discussion at the PTG
by Thierry Carrez 10 Nov '25

10 Nov '25

Hi everyone, A quick reminder that we'll have a session at 13:00UTC today in the PTG on how we can regroup the operators-facing activities between our various groups: the Ops meetup group, the Large Scale SIG, the Public Cloud SIG, the Scientific SIG... Join us if you can! -- Thierry Carrez (ttx)

2 2

LXB Removal and OVN migration
by Ricardo Cano 10 Nov '25

10 Nov '25

Hello openstack-discuss, With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN? I did come across this https://www.jimmdenton.com/migrating-lxb-to-ovn/ and that looks good as a one-shoit while biting the bullet and taking a full outage. However, I was wondering if it was possible to run lxb and ovn side-by-side and cut them over, say one network at a time. This particular deployment was stood up using openstack-ansible back in the rocky days (now running antelope) and it appears that openstack ansible's default was lxb up until Zed. Any suggestions or recommendations on the best path forward? Also, will the dynamic routing agent work with ovn?

4 3

[openstack helm] [Glance] Glance showing OSError: unable to receive chunked part when uploading image
by daniel890723＠gmail.com 08 Nov '25

08 Nov '25

Hello i'm testing using Openstack-helm to install all component but after the installation complete i can't upload the OS image through both openstack CLI or Horizon it stuck at Queueing and when i checking Glance Api log it shows 2024-11-07 07:31:19.362 7 INFO glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2024-11-07 07:31:19.400 7 ERROR glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Failed to upload image data due to internal error: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Caught error: unable to receive chunked part: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Traceback (most recent call last): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1302, in __call__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1345, in dispatch 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return method(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 415, in wrapped 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 299, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 162, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 492, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 443, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/quota/__init__.py", line 322, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 596, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 487, in _upload_to_store 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 397, in add_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 479, in store_add_to_backend_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/driver.py", line 294, in add_adapter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/capabilities.py", line 176, in op_checker 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 764, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise errors.get(e.errno, e) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 746, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi for buf in utils.chunkreadable(image_file, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 294, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = self.data.read(i) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 121, in readfn 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = fd.read(*args) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/format_inspector.py", line 956, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = self._source.read(size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1045, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi data = uwsgi.chunked_read() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Ceph Cluster Status: NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID ceph /var/lib/rook 3 82m Ready Cluster created successfully HEALTH_OK 5cf8b9bb-13e1-4c31-b47d-9e7d92c3c05d Ceph osd status: ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 0.35156 - 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 1.00 - root default -5 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 - host instance-lu-1 2 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 195 up osd.2 -3 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-2 0 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 195 up osd.0 -7 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-3 1 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 197 up osd.1 TOTAL 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 MIN/MAX VAR: 1.00/1.01 STDDEV: 0.01 now i'm able to create Empty Volume using horizon(can't create volume using default cirros image ) and i can start an Instance without volume and mount the empty volume in(Ceph also can detect when i use that volume) is there something i need to set when starting glance? because i'm following the Openstack-helm installation document to install openstack with helm

5 8

[watcher] Unmaintained branch cleanup
by Joan Gilabert 07 Nov '25

07 Nov '25

Hi everyone, Watcher currently has two unmaintained branches[1], unmaintained/2024.1 and unmaintained/2023.1. The latter has not had any patch in 2 years [2] so we plan to move it to eol. We will discuss it in the next Watcher IRC meeting, but I'm writing this message early to give everyone a chance to raise any objection. Please respond to this message if you have any objection, if there are none, I will propose a patch to move the branch next Thursday, after the Watcher IRC meeting and share the link here. Regards, Joan [1] https://opendev.org/openstack/watcher/branches [2] https://opendev.org/openstack/watcher/commits/branch/unmaintained/2023.1

2 2

[ops][largescale-sig][scientific-sig] Ops Radio Hour on October 31, 2025 at the PTG
by Ildiko Vancsa 05 Nov '25

05 Nov '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __October 31st, 2025 at 1300UTC,__ which is during the PTG! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. The main topic of the next gathering will be to discuss how to refactor Ops-related activities. See Thierry's email for more details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on October 31st! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[ironic][all] Making core teams more accessible
by Jay Faulkner 04 Nov '25

04 Nov '25

I'm going to preface this with a comment that I'm not completely sold on this idea yet, but I think it's worth a larger discussion and might be a seed to help with discussion. I've tagged Ironic as this proposal is for Ironic specifically, but I'm very, very interested in the larger community opinion for this kind of approach so I also tagged all. One of the toughest parts about walking the path to becoming core is how fuzzy the targets are. With Ironic recently having added a two-tier review system, with reviewers and approvers separate, we have an opportunity to allow a much, much bigger tent for the ironic-reviewers group without risking code getting merged without approval by one of our folks with more experience and context in OpenStack and Ironic as a whole. So here's the suggestion -- we come up with a static criteria and period with a clear bar to "if you do this, you are an ironic-reviewer". For instance, we could say (I'm not sure about these numbers): if you do an average of Y (5?) reviews/week and have merged a major Ironic feature or multiple bugfix patches, you would automatically be a reviewer. Obviously, we'd have to keep safeguards to prevent abuse; in our community in the past we had a rule that changes required review from two separate corporate entities -- in this case, I'd suggest a waiting period to prevent quick-merging by someone with a single perspective. Exceptions would be, as in the current system, for emergency CI fixes and documentation improvements. To be clear: the safeguards shouldn't be seen as a lack of trust, but maybe instead as an acknowledgement that structural controls hold value even if there's no reason to assume mistrust. Full proposal: * ironic-approvers (+2 and Workflow +1) continues to operate as usual, with admission being based on technical merit, trust, and review frequency. * ironic-reviewers (+2 only) becomes a data-driven group, where reviewers are added/removed based on individual performance metrics TBD (likely reviews/commits/bugs fixed). -- I'll note that today, there's not really any set of reasonable metrics that would add additional reviewers to this group. * Code changes would either need a review from two separate company-representatives, or to have sat for a short waiting period to ensure other folks had a chance to look at it. * Urgent CI fixes, trivial changes, and documentation updates would still only need one review to land. What do folks think? Would this be a good carrot for existing non-cores to up their review and upstream contribution commitments? - Jay Faulkner G-Research OSS

6 6

Kolla-Ansible deployment results in broken dashboard
by Ricardo Matheus 04 Nov '25

04 Nov '25

Hi all I just deployed a multinode OpenStack using Kolla-Ansible, but it seems that the Horizon image (ubuntu / master) is somewhat broken. Horizon runs and the dashboard is accessible, but every file in the "static" part of the web server is not available (no logo images, no css, nothing... just plain unformatted html). Is this a known bug? (btw, there was a guy asking about the same problem in irc a few days ago, it is in the logs for 2025-10-23 (Thursday) <https://meetings.opendev.org/irclogs/%23openstack/%23openstack.2025-10-23.l…> ) Cheers! RDM

2 2

[ironic] Stop maintaining sushy as a separate project, let's move it into ironic
by Iury Gregory 02 Nov '25

02 Nov '25

Hello everyone! During the PTG yesterday, we discussed stop maintaining sushy as a separate project. For those who don't know what sushy is: a Python library to communicate with Redfish based systems and is limited to what Ironic supports. The library was never intended for others to consume, yet that has happened, and it being a library has been a noted hurdle to quickly resolving user issues, because it requires releasing a new version. But before we move this forward, we would like to hear from you what are your thoughts. Thanks! -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core - Ironic Event Liaison (DPL)* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

6 6

[nova][glance] Image corruption during shelving
by Vladimir Prokofev 31 Oct '25

31 Oct '25

Hello everyone. I've discovered a bug in nova/glanceclient interoperation that leads to image corruption during shelving under some circumstances involving connection disruption. I was able to reproduce it in two different production environments running on xena and 2024.2 respectively, I'm also able to reproduce it in devstack though without image corruption - there it just ends up in a shelve failure due to detected corruption. My setup assumes LVM-backed QEMU VMs with backend in CEPH for Glance, but I believe this is applicable to a variety of nova/glance backends. When shelve is triggered, nova-compute creates an image file locally, and then initiates upload of said image file into Glance[0]. If something happens to the connection during the upload("broken pipe", "connection timeout") - nova-compute retries upload operation[1] while image object is removed from CEPH backend by Glance[2] Problem here is that the image_file object that is passed to glanceclient by nova-compute is a byte-stream created with an open()[3] call, and upon retry it resumes the upload from the point where it was interrupted. This is easily confirmed by calling image_data.tell() in glanceclient.v2.images.Controller.upload() function - it will be at zero initially and non-zero on retry. I haven't thoroughly checked protection offered in Glance master, I believe it may have been significantly improved, but in older releases such as 2024.2, this leads to a corrupted shelved image, because upon retry only part of an image object is uploaded, after which original VM is offloaded(removed) and you end up with lost data. Now, my issue here is where to submit this bug: glanceclient or nova? This problem is easily fixable in glanceclient by calling image_data.seek(0) in glanceclient.v2.images.Controller.upload(): it makes sense to always point byte-stream to the beginning before initiating upload, but should it really be responsibility of a client to perform such a sanity check? I'm also not sure if there're cases that this will break, for example if a non-seekable object is passed into glanceclient, but I'm not sure if this is even possible? [0] https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/driv… [1] https://opendev.org/openstack/nova/src/branch/master/nova/image/glance.py#L… [2] https://opendev.org/openstack/glance_store/src/branch/master/glance_store/_… [3] https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/driv…

2 2

[ptg] Image Encryption Session, Thursday 30th @ 16:00 UTC
by Markus Hentsch 30 Oct '25

30 Oct '25

Dear OpenStack community, in preparation for the vPTG discussion slot for the image encryption (Thursday 30th at 16:00 UTC) I collected a summary explaining the key points and state of the contribution and gathered some discussion topics below. Since this spans multiple projects (mainly Glance, Cinder and Nova) and has been ongoing for quite some years, I tried my best to briefly summarize the most important aspects of the current state so that all those who wish to participate have the latest information. The text below can also be found on the etherpad: https://etherpad.opendev.org/p/2026.1-ptg-glance-planning#L128 Summary: - historically, only Cinder has been able to create and use encrypted images (as a side effect) by dumping LUKS-encrypted volumes 1:1 into images, for exclusive use in Cinder - this contribution aims to introduce encrypted image functionality for the end user: images can be encrypted/decrypted outside of OpenStack and resulting (encrypted) image is stored in Glance and the key in Barbican - goal: standardize encrypted image formats and handling across Glance, Cinder and Nova - it introduces two formats: raw LUKS and qcow2-wrapped LUKS (native qcow2 feature) - it introduces new key handling: if Barbican secret is of type 'passphrase' it is used as the LUKS key as-is; if it is of any other secret type, it is assumed to be binary and converted via 'binascii.hexlify()' (preserves Cinder behavior and compatibility) - it makes use of the new secret consumer API in Barbican to prevent accidental key deletion (since keys may be managed by users, not OpenStack), registering images as consumers to their keys - note: the image encryption feature focuses on Glance and Cinder for now, Nova has been largely excluded so far due to ephemeral storage encryption not being ready yet Implementation State (note: aside from os-brick this is not merged yet!): - os-brick: implemented outsourced utility function to discern encryption between passphrase and binary (hexlify conversion) for shared usage by Nova and Cinder - Glance: implemented new encryption-specific image formats and properties as well as secret consumer handling - Cinder: implemented encrypted image usage for volumes: LUKS is handled as raw (like before) and qcow2+LUKS is converted; image creation from volume stays limited to raw LUKS - Nova: implemented only compatibility with os-brick and Cinder changes so far - barbican-tempest-plugin: full scenario tests (image > volume > server > SSH) for 4 permutations of the image encryption Patchsets: https://review.opendev.org/q/topic:%22LUKS-image-encryption%22 Discussion Topics: 1) Image inspection: related to CVE-2024-32498 concerns were brought up about encrypted image payload containing malicious formats triggering unintended QEMU behavior; how to screen encrypted image payload and reject undesired formats? 1a) limiting to specific formats has consequences for Cinder: attached (secondary) encrypted volumes might contain arbitrary binary data in VMs (user choice), when uploading as image to Glance it might be rejected as prohibited format; additionally, such image vanishes without trace because there is no error state for images (bad Glance <-> Cinder interaction) - how to address this? 1b) how deep do we want to look into encrypted image payload? decrypting a 1TB image might be very costly (CPU load, disk space) - problem: "qemu-img convert" cannot stream to stdout (see https://blogs.igalia.com/berto/2025/07/15/converting-qemu-qcow2-images-dire… ); in the worst case we have to wait for the full 1TB to be decrypted, consuming almost twice the amount of disk space in the process, instead of being able to only read the payload header and abort 2) Nova integration: how to approach future interoperability with ephemeral storage encryption? 2a) can we handle this as separate future expansion to this feature, i.e., merging Glance+Cinder functionality short-term with only compatibility changes in Nova for now and addressing full Nova integration as a next step with dedicated patchsets based on the current work? 3) Better organization: would there be any interest in reviving the image encryption popup-team meeting? https://meetings.opendev.org/#Image_Encryption_Popup-Team_Meeting Best regards, Markus Hentsch -- Markus Hentsch DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 00 markus.hentsch(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

2 3

[skyline] possible small bug in skyline
by Taavi Ansper 30 Oct '25

30 Oct '25

Hi I have found a possible small bug in skyline. I didn't know where to post this in bugzilla. https://bugs.launchpad.net/skyline-apiserver/+bug/2129915 The bug comes from the placement API request to: //resource_providers/1ab32e69-ee87-4ccb-bd8a-b39abfa4a980/inventories The same UI view in horizon works nicely and it doesn't append the the double slash in the API request. Where might this come from the code? Something related to this is defined here, but it probably comes from the "Base" stuff: https://github.com/openstack/skyline-console/blob/stable/2025.1/src/client/… https://github.com/openstack/skyline-console/blob/stable/2025.1/src/client/… This issue appeared after upgrading from 2024.2 to 2025.1 Best regards -- ---- Taavi Ansper taavi.ansper(a)cyber.ee

1 0

[openstack][kolla-ansible]about group node config overwrite
by Nguyễn Hữu Khôi 30 Oct '25

30 Oct '25

Hello Koller. I want to ask if we can overwrite config for a group of nodes. For example, compute01 >> compute10 will have the same nova configuration compute11 >> compute20 will have the same nova configuration. It will be very nice if we support this way. Thank you. Regards Nguyen Huu Khoi

4 7

[nova][glance] Server rescue falls back to default image
by Francesco Di Nucci 29 Oct '25

29 Oct '25

Hi all, I am on OpenStack Caracal, trying to rescue a VM that's not booting: * I previously created a SystemRescueCD rescue image (with openstack image create --file ./systemrescue-12.02-amd64.iso --disk-format raw --container-format bare --property hw_rescue_bus=virtio --property hw_rescue_device=disk systemrescuecd_1202) - it works on VMs that still have their base images in Glance * tried to rescue the VM (with openstack server rescue --image systemrescuecd_1202 my-vm-id-here) * but the process fails as it tries to also use the base image used to create that VM, instead of the rescue image only (Instance my-vm-id-here cannot be rescued: Driver Error: Image b78cf456-b395-434f-bf50-a1f2f3684a37 could not be found. ; where b78cf456-b395-434f-bf50-a1f2f3684a37 was a Ubuntu cloud image used to create that VM, since deleted as it's an EOL version) Is it supposed to also try to use the base image or should the --image bypass it? In case, what could I do? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

3 2

[kolla-ansible] Rabbitmq queue creation issues in "fresh" 2025.1 deploy
by Jonathan Proulx 28 Oct '25

28 Oct '25

Hi All, I'm putting "fresh" in quotes becuase I expect the issue is some home my deploy isn't as fresh as I belive it to be. I did have and older test environment which was serveral steps behind (and not quite workign for other reasons). The presenting issues is this error (and other similar ones for other services): 2025-10-24 11:44:07.840 1076 WARNING oslo.messaging._drivers.impl_rabbit [None req-4eff1f78-c16a-4bc9-b0da-9ce0a80b66ba - - - - - -] [83941886-4e9c-4d0c-b3b0-53c107f018e9] Queue conductor could not be declared probably because of conflicting configurations: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'true' but current is 'false': amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'true' but current is 'false' 2025-10-24 11:44:07.841 1076 INFO oslo.messaging._drivers.impl_rabbit [None req-4eff1f78-c16a-4bc9-b0da-9ce0a80b66ba - - - - - -] [83941886-4e9c-4d0c-b3b0-53c107f018e9] Retrying to declare the exchange (nova) as non durable I'm puzzled since the services are deploying to recently reinstalled nodes (I'm sure that part is fresh) how the queues can be created with flags the services don't expect. my shell history tells me I'm using these versions (in a venev): pip3 install --upgrade git+https://opendev.org/openstack/kolla-ansible@stable/2025.1 pip3 install --upgrade git+https://opendev.org/openstack/kolla@stable/2025.1 pip3 install --upgrade 'ansible-core>=2.17,<2.18.99' The only bits I know are left over and "upgraded" from previous attempts are my configs in /etc/kolla. My deploy host wasn't reinstalled but I did delete and recreate the venv. Using Ubuntu 24.04 as the base OS Where do I go from here to find my wrong turn? Thanks, -Jon -- Jonathan "Some Day I'll Upgrade From Mitaka" Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 4

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

28 Oct '25

Hi, Thanks for the comments, and let me try to group some & reply ahead of the PTG session. 1- Quantum computers are no threat, they are underpowered, so what’s the risk & why should we do anything now? * The issue is time. The day a quantum computer is powerful enough to break traditional cryptography (known as Q-day), it is too late. OpenStack lays naked and vulnerable. * We can argue about dates, and my current opinion is that to be on the safe side, any software product should implement PQC cryptography by 2029. * We have a large code base, and we need to give time to the community to review & adjust it then to openstack operators to implement quantum-safe cryptography. * There is no snake oil/panic-driven agenda here, either we protect access to OpenStack infrastructure & between services, preferably by 2028. Or we don’t. We have time, but we should start work now. 2- It’s a problem for Operating System vendors, we just consume their cryptography. * I wish it were true. But the initial analysis I made demonstrates we have libraries that do cryptographic operations, and maybe these libraries end up properly calling an OS cryptographic module. Maybe not. I know of paramiko, that does not call any OS layer, but its own copy of OpenSSL code. We cannot assume OpenStack has nothing to do until we analyse our cryptographic usage. * I totally support the idea of using OS cryptography as much as possible, because we offload the maintenance problem to OS vendors. * Then because new fancy cryptographic algorithms have been finalized (key encapsulation, ML-KEM), or near finalized (digital signature, ML-DSA) does not indeed mean they are available in all the protocols that uses them (IPsec, kerberos, dnssec…) in operating systems. 3- Some of the libraries listed might no longer be in used. * The code should be removed from OpenStack. We have customers doing Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST): these will flag those unsafe modules. * Other side of that point: some of these libraries are still used. Do they rely on an operating system cryptography, or do they pull their own cryptographic call? Are they maintained? Should we reduce the amount of cryptographic modules in OpenStack? 4- There is no plan proposed, what’s next? * Initial email was to express my concern about supporting PQC in OpenStack, understanding if my concern was shared, and raise awareness on this topic right ahead of the PTG. * The first step to solve a problem is to know there is a problem, I’d start with a per project effort starting with a simple question for projects: "Does your project do anything in relation to keys, encryption, or interaction of any encrypted data either at rest or while in transit?" * Next would be to use those results to plan for protecting OpenStack against the store-now, decrypt-later attacks, meaning protecting key exchanges relaying on ML-KEM (well hybrid X25519MLKEM768 to start with), ensuring symmetric keys are long enough (256 bits minimum), then deal later with digital signatures code (if any). 5- The goal is premature * I consider this a community goal because all OpenStack components must achieve support pretty much in the same time frame. I am not saying it should take precedence over any other critical work (e.g., eventlet removal), I think now is the time to scope the work and plan to meet the 2027/2028 deadline. * OpenStack customers planning to run it well into the 2030s are asking about the plans for PQC support. And new customers considering OpenStack are asking about PQC support plans. Either we have an answer, a roadmap, or OpenStack will not be part of the discussion, at some point (ask me how I know :-). Regards, JP

1 0

pip 25.3 removes support for legacy editable installs
by Stephen Finucane 28 Oct '25

28 Oct '25

o/ pip 25.3 was released on Friday (who does Friday releases?!) and had removed support for the legacy `setup.py develop` editable install method in setuptools [1]. Now, thankfully most services seem to have listened to me [2][3] and the shouty warnings from setuptools/pip and migrated away from 'wsgi_scripts'. However, there is a good chance that older stable branches are missing these migration patches and consequently now broken. For example, it seems keystone is missing these changes on stable/2024.2, and attempts to deploy that branch currently fail with: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Internal Server Error (HTTP 500) which, upon further inspection, will turn out to be a missing wsgi script: devstack(a)keystone.service[40466]: failed to open python file /opt/stack/data/venv/bin/keystone-wsgi-public We have already seen this pop up on the cluster-api-provider-openstack (CAPO) project [4], which is using the old stable/2024.2 (Dalmatian) release. I have proposed fixes to stable/2025.1 [5] and stable/2024.2 [6] to constrain pip on those older branches. This should fix the issue for everyone, provided you're not using a devstack plugin that re-updates pip. Individual services may also wish to backport the patches that added '$service.wsgi' modules if possible, to fix this for non-devstack use cases, but this won't be possible in all cases. Hope this helps, Stephen [1] https://pip.pypa.io/en/stable/news/#v25-3 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/28… [5] https://review.opendev.org/c/openstack/devstack/+/965092 [6] https://review.opendev.org/c/openstack/devstack/+/965093

2 1

[keystone][ptg] Keystone PTG schedule is available (Tue and Wed)
by Artem Goncharov 28 Oct '25

28 Oct '25

Hey guys, The Keystone team is meeting today and tomorrow for the PTG. Today's focus are the federation topics, passkeys, service accounts and discussion of feature deprecation that depend on the software abandoned upstream (i.e. saml2). Tomorrow we are going to focus more on the cryptography used in Keystone, Horizon cross-session and certain cli aspects. You are very welcome to join us discussing the future of Keystone. TECHs of today put big challenges in front of us and we need to do rework no matter how hard and painful it is. https://etherpad.opendev.org/p/oct2025-ptg-keystone Regards and see you in already a bit Artem

1 0

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2026
by Piotr Kliczewski 28 Oct '25

28 Oct '25

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2026, to be hosted on 31st of January. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by 5th December 2025. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM, libvirt, shared storage, virtualized networking, cloud security, clustering and high availability, interfacing with multiple hypervisors, hyperconverged deployments and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 5th December 2025 Acceptance notifications: 10th December 2025 Final schedule announcement: 15th of December 2025 Devroom: 31st of January Submit Your Proposal During submission [1] please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, Piotr Kliczewski and Tal Nisan In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM[2], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] https://fosdem.org/2026/practical/conduct/

1 0

[swift][ptg] Ops Feedback Session - 29th October at 1300 UTC
by Matthew Oliver 28 Oct '25

28 Oct '25

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the gazpacho swift meetpad room ( https://meetpad.opendev.org/swift-ptg-gazpacho) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-gazpacho-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

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

28 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 28 Oct '25

28 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 27 Oct '25

27 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 25 Oct '25

25 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 23 Oct '25

23 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

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 22 Oct '25

22 Oct '25

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

3 5

[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

[Ceph Tracing] Limited Jaeger traces for OSD, no MON/MGR/RGW
by Thamanna Farhath 21 Oct '25

21 Oct '25

Hi Ceph Team, We’ve enabled Jaeger tracing in our Ceph cluster using: ceph config set global jaeger_tracing_enable true Currently, only OSD traces (e.g., enqueue_op, op-request-created) are visible, while MON, MGR, and RGW traces are missing. I noticed PR https://github.com/ceph/ceph/pull/59365 adds more tracers but hasn’t been merged yet. Could you please confirm: If this is an ongoing bug or current limitation? Whether there’s an alternative branch, backport, or workaround to achieve full tracing coverage? Appreciate your guidance. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 3