- openstack-discuss - lists.openstack.org

[nova][cinder][neutron] Heartbeat improvement: checking if main thread responds to rabbit ping
by Thomas Goirand 30 Dec '25

30 Dec '25

tl;dr: I want to implement main thread ping in the heartbeat tread via rabbitmq to make sure the main thread is alive when reporting a service status, I'd like to have opinions. Hi, I already wrote about this on #openstack-cinder, but nobody replied to me. Anyways, I think it's a topic that is cross-project, so I want to open it in this list. After a rabbitmq outage due to a disk full in our infra, we restarted our rabbitmq cluster. Everything seemed to come back normally, but we later discovered that the main threads of cinder-volume and cinder-backup were dead, while the heartbeat thread was not, and was reporting the services as up. It took us some time to realize it, as this cluster isn't public cloud, and we could live with the errors. Though we don't want to leave things the way they are, as we want reliable monitoring to avoid painful support tickets from customers. Within Cinder, there's already all the infrastructure in place to enhance the hearbeat thread, and make it do more checks. However, currently, the Manager class isn't even instantiated and used when creating the service. Here's my proposal, currently only for Cinder, but hopefully, I'll also implement it in Nova and Neutron. When creating the cinder-volume using cinder/service.py, it's going to also create a manager, and attach it to the service. The ManagerVolume class will implement the is_working() method of the class Manager. In it, it's going to ping the main thread with rabbitmq, sending a ping message, to which the main thread must respond with a pong. If the pong isn't received within a timeout, is_working() will reply False. I started implementing it here: https://review.opendev.org/c/openstack/cinder/+/970796 Note that it's currently still a WIP, and there's more to work on, like some unit tests that are currently failing. I'm not posting the link to the patch to get a merge yet, and it's unfinished, but the current patch is probably enough to get the idea of what I want to implement. So, for each service, the heartbeat will do a ping, which will of course make more messages in Rabbit. Though I believe this is still a reasonable thing to do. With 200 Cinder service, and a heartbeat every 30 seconds per service, that's going to be an additional less than 15 messages per seconds. Considering a reasonable RabbitMQ service can eat 100k message per seconds, it should be ok. Now, this is for Cinder. Once it's done there, I intend to investigate Neutron next, but I'm not sure if it has all the facilities that Cinder offers. Maybe it'd be worth unifying this in oslo.messaging? I'm open to suggestions, but I'm unsure (yet) of what it would look like within one of the oslo libs (I'd have to look on how / where to do it: suggestions are welcome, as it would speed-up my work on it). Please let know your opinion on this, if this is a good idea or not, and if the Cinder team (and potentially Neutron and Nova) will be willing to accept such a patch. Cheers, Thomas Goirand (zigo)

3 4

[Nova] unified limit and pci alias combination support
by Masahito Muroi 30 Dec '25

30 Dec '25

Hi Nova folks, We're trying to use unified limit with alias PCI device information with following configuration. With this configuration, unified limit calculates the resources:CUSTOM_NVIDIA_T4 correctly, but nova-scheduler makes allocation_candidate request with duplicated CUSTOM_NVIDIA_T4 resources. From my quick check of the code, the unified limit and pci device alias usecase is not supported by the master branch now. I'm thinking to fix the issue and comming up with two idea to solve the issue. I want to hear the nova team's opinion which is better to fit the nova's code. Or please give me any comment if there is another better way. - idea1: nova-scheduler drops duplicated resources request if needed. Adding a configuration to drop duplicated situation and etc. - idea2: introduces a new flavor extra spec prefix, e.g. "placement:<RC>", to indicate the resource class comes from placement. # nova.conf [pci] device_spec = {"vendor_id":"8086", "product_id":"8d2d", "resource_class":"CUSTOM_NVIDIA_T4"} alias = {"name":"t4_pcie_16gb", "vendor_id":"8086", "product_id":"8d2d", "resource_class":"CUSTOM_NVIDIA_T4", "device_type":"type-PCI"} report_in_placement = true pci_in_placement = true [quota] driver = nova.quota.UnifiedLimitsDriver unified_limits_resource_strategy = require unified_limits_resource_list = class:CUSTOM_NVIDIA_T4, class:VCPU, class:MEMORY_MB, class:DISK_GB # openstack flavor show GPU_FLAVOR | Fields. | Value | +-------------+-----------------------------------------| | properties | pci_passthrough:alias='t4_pcie_16gb:1', | | | resources:CUSTOM_NVIDIA_T4='1' | # allocation candidate request query /allocation_candidates limit=1000 resources=CUSTOM_NVIDIA_T4:1 DISK_GB:10 MEMORY_MB:1024 VCPU:1 resourcesbb775ad3-f50c-4d3b-bb28-8993e4a664ca-0=CUSTOM_NVIDIA_T4:1 best regards, Masahito

2 1

Continuous Audit Stuck in PENDING State
by Mohd Atif Ansari 29 Dec '25

29 Dec '25

Hello OpenStack Community, I am facing an issue with Continuous Audits in Watcher. After creating the audit with an interval, the audit remains in the PENDING state and does not generate any action plans. All Watcher services are running, and the audit is created successfully without errors. Could you please help identify what might be missing or misconfigured? I have attached some screenshots for your reference. Thanks, Mohd Atif Ansari 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."

1 0

How to correctly pass a Heat template in Mistral heat.stacks_create action?
by elnazcloud＠gmail.com 27 Dec '25

27 Dec '25

I am trying to deploy a Heat stack from a Mistral workflow using the built-in heat.stacks_create action. Mistral and Heat services are working fine, but whenever I provide a Heat template through the workflow, the execution fails with: “Template not in valid format: The template is not a JSON object or YAML mapping” The same Heat template deploys successfully with the standard openstack stack create command, so the template itself is valid. My question is: What is the correct and supported format for passing a Heat template into heat.stacks_create؟

1 0

[Masakari][HA][Antelope] Host failure not detected in 3-node controller+compute cluster
by Thamanna Farhath 23 Dec '25

23 Dec '25

Hello OpenStack community, I am testing Masakari host failure recovery on OpenStack 2023.1 (Antelope) deployed using Kolla-Ansible. Environment: 3 nodes Each node runs controller + compute Pacemaker + Corosync deployed on all 3 nodes Masakari enabled (hostmonitor, instancemonitor, engine, api) pacemaker-remote not used (all nodes are full Pacemaker members) Masakari segment: service_type = COMPUTE recovery_method = auto Tests performed: Process-level failures (qemu, libvirt) → detected correctly nova-compute stop → detected (no evacuation, expected) Host failure test: Powered off one compute/controller node Also tested systemctl stop corosync Issue: Pacemaker shows the node as OFFLINE However: No Masakari HOST_DOWN notification is generated No evacuation is triggered masakari-hostmonitor logs do not show host failure handling Question: In a 3-node controller+compute Pacemaker cluster, is Masakari expected to detect host failure directly from Pacemaker membership events without pacemaker-remote? Are there any additional requirements needed for Masakari host failure detection in this topology? Any guidance or references would be greatly appreciated. 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."

3 2

[Masakari] Proposal to restart bi-weekly IRC meetings (poll for the 1st session)
by Sei Sano 22 Dec '25

22 Dec '25

Dear Kajinami, Sam Su (苏正伟) I’d like to restart the regular Masakari IRC meeting, which has been paused for a while, and resume it on a bi-weekly basis. Also, through the Japan OpenStack user community network, I have already reached out to a few people who are interested in Masakari (they are welcome to join as observers at first). As a first step, I propose holding a kick-off meeting to align on how we run the meeting going forward (bi-weekly schedule, agenda/minutes process, chair rotation, etc.). Could you please let me know your availability for the first meeting from the options below? * Option 1: Friday, 2025-12-19 06:00-07:00 (UTC) / 15:00-16:00 (JST) * Option 2: Monday, 2025-12-22 06:00-07:00 (UTC) / 15:00-16:00 (JST) * Option 3: Tuesday, 2025-12-23 06:00-07:00 (UTC) / 15:00-16:00 (JST) Please reply by 2025-12-17 23:59 UTC. If I don’t hear back by then, I will go ahead and schedule the first meeting on (tentatively) 2025-12-22 06:00-07:00 (UTC) / 15:00-16:00 (JST), so we can start moving again (and we can adjust for the next meeting if needed). Proposed location: OpenStack IRC (#openstack-masakari) Draft agenda: * Agreement to restart the regular meeting (bi-weekly cadence, day/time) * Near-term priorities (review backlog, bugs, releases/events, blueprints, etc.) * Lightweight meeting operations (chair/agenda/minutes) If you have any constraints (e.g., specific time windows that never work), please share them as well. Thanks, -- Sei Sano NTT DOCOMO BUSINESS, Inc. E-mail: sei.sano(a)ntt.com

2 6

[deployment][kolla][rabbitmq] RabbitMQ errors
by Taavi Ansper 22 Dec '25

22 Dec '25

Hi I am seeing a lot of errors regarding rabbitmq. Our Openstack deployments work, but it is littered with these kinds of messages. 2025-12-22 15:41:47.026 1078 ERROR oslo.messaging._drivers.impl_rabbit [None req-0f284b85-9d30-4696-8246-c79da103b149 - - - - - -] [89e1e73c-56eb-4618-b775-9055444c9015] AMQP server on 192.168.X.X:5672 is unreachable: connection already closed. Trying again in 1 seconds.: amqp.exceptions.RecoverableConnectionError: connection already closed 2025-12-22 15:41:46.792 1117 ERROR oslo.messaging._drivers.impl_rabbit [-] Unable to connect to AMQP server on 192.168.X.X:5672 after inf tries: Basic.consume: (406) PRECONDITION_FAILED - stream queue 'q-reports-plugin_fanout' in vhost '/' does not have a running replica on the local node: amqp.exceptions.PreconditionFailed: Basic.consume: (406) PRECONDITION_FAILED - stream queue 'q-reports-plugin_fanout' in vhost '/' does not have a running replica on the local node 2025-12-22 15:41:46.257146+02:00 [error] <0.39571548.0> operation basic.consume caused a channel exception precondition_failed: stream queue 'central_fanout' in vhost '/' does not have a running replica on the local node Why is this happening and what should I do or keep in mind? -- ---- Taavi Ansper taavi.ansper(a)cyber.ee

1 0

[watcher] Dec 25th and Jan 1st meetings cancelled
by Douglas Viroel 19 Dec '25

19 Dec '25

Hi all, The watcher team agreed[1] on cancelling the following two weekly meetings (Dec 25th and Jan 1st) due to holidays (in most of the countries). We will meet again on Jan 8th. Thank you all and happy holidays! BR, [1] https://meetings.opendev.org/meetings/watcher_meeting_11_dec_2025/2025/watc… -- Douglas Viroel - dviroel

1 0

[blazar] Meeting cancelled for 25 December 2025
by Pierre Riteau 19 Dec '25

19 Dec '25

Hi all, Due to lack of availability of the core team, the fortnightly Blazar meeting will be cancelled on December 25. Have a nice break! Pierre

1 0

[manila] Next two weekly meetings cancelled
by Carlos Silva 19 Dec '25

19 Dec '25

Hello everyone, The manila team is cancelling the two upcoming weekly meetings (Dec 25 and 31) as these are holidays in a bunch of countries and people are taking time off. We'll resume the manila weekly meetings on Jan 8th. Hope you have a great break! Regards, carloss

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on December 19, 2025
by Ildiko Vancsa 19 Dec '25

19 Dec '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 __December 19th, 2025 at 1300UTC,__ which is this Friday! 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. Topics for this call: - As this is the last call of the year, we can utilize it to have a retrospective on the call series and talk about plans for 2026. - We also had a great discussion at the PTG session about how to refactor Ops-related activities, which we can keep exploring for further increased collaboration between related groups: * See Thierry's email for initial details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… * Meeting notes from October 31st: https://etherpad.opendev.org/p/openstack_ops_radiohour 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> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + 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 December 19th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[skyline] possible bug in OIDC usage with skyline
by Taavi Ansper 18 Dec '25

18 Dec '25

Hi We are testing kolla-ansible 2025.2 and we have found a possible bug in skyline. When using OIDC and trying to log in we get an error that looks like this: { "detail": [ { "type": "string_pattern_mismatch", "loc": [ "header", "X-Openstack-Request-Id" ], "msg": "String should match pattern '^req-\\w{8}(-\\w{4}){3}-\\w{12}'", "input": "", "ctx": { "pattern": "^req-\\w{8}(-\\w{4}){3}-\\w{12}" } } ] } Any help or guidance is appreciated :) -- ---- Taavi Ansper taavi.ansper(a)cyber.ee

3 5

#eventlet-removal Thank you for 2025
by Herve Beraud 18 Dec '25

18 Dec '25

Two years ago, we collectively acknowledged that we were facing a demanding and somewhat paradoxical challenge: engaging a significant amount of time and resources to move away from a problematic technology, eventlet, without the promise of immediate functional gains. At that time, this effort could easily have been perceived as a necessary but uncomfortable burden — work that does not ship new features, does not directly address new user requests, and yet requires deep focus, coordination, and perseverance. We deliberately chose not to ignore the problem, not to postpone it, and not to settle for half-measures. Today, as we are reaching the end of 2025, we can clearly state that this choice was the right one. This year has been particularly intense, productive, and revealing of what a committed open source community can achieve when it aligns behind a long-term objective. The migration effort has reached a decisive milestone: more than 61% of the impacted OpenStack deliverables have now shown significant progress. Twenty deliverables are fully migrated, while forty others are actively undergoing migration. More than 424 Gerrit patches proposed this year alone directly contribute to this collective effort. Beyond the numbers, 2025 has delivered concrete, structural results. Several major projects — including Ironic, Heat, Barbican, Mistral, and others — are now fully migrated. Eventlet itself has evolved, gaining support for recent Python versions (3.12, 3.13, 3.14), ensuring compatibility with modern OpenStack runtimes during the transition phase. Oslo.service introduced a new threading backend, offering a fully threading-based execution model. Cotyledon is actively progressing toward supporting new spawning methods. Neutron is now just one step away from completing its migration, Nova can run specific services in threading mode, and teams such as Cinder, Designate, Watcher, Cyborg, and many others have shown sustained and visible momentum. What we are witnessing is more than a migration. It is a collective act of responsibility. Just like the Python 2 to Python 3 transition, this effort is about securing the future, reducing systemic risk, simplifying maintenance, and restoring long-term innovation capacity. It is about choosing durability over comfort, clarity over accumulation, and sustainability over short-term convenience. The foundations we are laying today are already making OpenStack more robust, more predictable, and better prepared for what comes next. As we close this year, I want to express my sincere respect and gratitude to everyone involved. Maintainers, contributors, reviewers, operators, companies — your engagement, patience, and persistence have made this progress possible. The level of coordination and trust demonstrated throughout 2025 is a strong signal, not only for our community, but for the entire industry that relies on OpenStack. On behalf of this community initiative, thank you for your commitment throughout this year. You have proven, once again, that necessary work — even when it does not immediately shine — is often the work that matters the most. I wish you all restful holidays and precious time with your loved ones. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

2 1

[ops][publiccloud-sig] no Public Cloud SIG meeting d.d. 31 December
by Kees Meijs | Nefos 17 Dec '25

17 Dec '25

Hello Stackers, The bi-weekly Public Cloud SIG meeting scheduled on 31 December will be cancelled due to the holiday season. See you next year, and enjoy your time off! 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 0

[horizon] Cancelling weekly meetings on Dec 24 and Dec 31
by Tatiana Ovchinnikova 17 Dec '25

17 Dec '25

Hello team, SInce the holiday season is starting, I am cancelling the next two IRC weekly meetings on December 24 and December 31. See you all on January 7, 2026. Happy holidays! With kind regards, Tatiana

1 0

[neutron] CI, Team and Drivers meetings canceled next two weeks
by Brian Haley 17 Dec '25

17 Dec '25

Hello Neutrinos: As mentioned at our weekly meeting, I am going to cancel the Neutron CI, Team and Drivers meetings for the next two weeks as most of us will be out-of-office the remainder of the year. Next meetings will be week of January 5th. Have a happy holidays! -Brian

1 0

OpenInfra Foundation 2025 Annual Report Now Available
by Allison Price 17 Dec '25

17 Dec '25

Hi everyone, The OpenInfra Foundation 2025 Annual Report is now published. Many of the themes in the report will be familiar to the OpenStack community, but this serves as a snapshot of how your work over the past year fits into the Foundation’s broader progress and direction. From an OpenStack perspective, the report highlights: Continued production adoption and momentum, reflected in the latest User Survey data and two coordinated releases in 2025. OpenStack’s role as a foundation for modern workloads, including AI infrastructure, edge and telco platforms, and sovereign cloud deployments. Ongoing collaboration across projects, showing how OpenStack works alongside Kata Containers, StarlingX, Zuul, Kubernetes, Ceph, and other open infrastructure technologies. Community visibility and events, including OpenInfra Summit Europe and regional activities where OpenStack users and contributors shared real-world experiences. Read the full report here: https://openinfra.org/annual-report/2025 Share with your network: https://www.linkedin.com/posts/openinfra-foundation_today-weve-published-th… Thank you to everyone who contributed code, reviews, docs, testing, operations experience, and community leadership in 2025. The impact captured in this report is a direct result of the OpenStack community’s continued commitment to building and operating open, production-grade cloud infrastructure. Cheers, Allison

1 0

[cinder] festival of reviews friday 2025-12-19
by Brian Rosmaita 17 Dec '25

17 Dec '25

Hello Argonauts, This is a reminder that the pre-holiday edition of the Cinder Festival of Reviews (last one this year!) will be held at the end of this week on Friday 19 December. who: Everyone! what: The Cinder Festival of Reviews when: Friday 19 December 2025 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

[magnum] Next meeting 20th Jan 2026
by Dale Smith 16 Dec '25

16 Dec '25

Due to holidays, we are taking a break and the following two meetings (23 Dec and 6 Jan) are cancelled. Meetings will resume on 20th Jan 2026. For more meeting details refer to https://etherpad.opendev.org/p/magnum-weekly-meeting -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 0

[ironic] Retirement of VirtualPDU
by Jay Faulkner 16 Dec '25

16 Dec '25

Hi all, As it's clear the SNMP code in Ironic will be removed next cycle, and CI has been removed as well, we also will be needing to retire VirtualPDU as well -- either this cycle or next. VirtualPDU was never shipped for production use and only mapped SNMP calls into libvirt power actions for devstack. With these jobs removed, it no longer serves a purpose. Please speak up now if you oppose this retirement. Thanks! -- Jay Faulkner Open Source Developer G-Research OSS

1 0

[qa] Onboarding contributors in QA
by Ghanshyam Maan 16 Dec '25

16 Dec '25

Hello Everyone, As you might know that we need more contributors in QA projects[1], I have started a etherpad to onboard new or current OpenStack contriburtors with all the deatils which includes: - Onboarding steps/information in OpenStack: this is for the new contributors in OpenStack - QA projects list and their documentation link - Current working item and help needed: this list will be evolving over time based on current working item. Currently I have listed the open bugs and moving tempest tests to SRBAC defaults. - https://etherpad.opendev.org/p/qa-onboarding I have four contributors started working on moving tempest testst to SRBAC defaults. If you or someone form your organization is interested, feel free to ping me or add your name in etherpad. [1] https://governance.openstack.org/tc/reference/upstream-investment-opportuni… -gmaan

1 0

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 17 December
by Kees Meijs | Nefos 16 Dec '25

16 Dec '25

Hello Stackers, Tomorrow (that's 17 December) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! 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 0

[OpenStack Ansible] [Deployment] Depolyment errors
by holywine＠outlook.com 16 Dec '25

16 Dec '25

Hello, Trying to deploy OpenStack on 5 hosts (3 infra, 2 compute). During executing command "openstack-ansible openstack.osa.setup_infrastructure" following errors occurred. Can anybody please provide a clue on what went wrong? Thanks in advance! 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| container_name: "infra1-repo-container-0b24c04d" 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| physical_host: "infra1" 2025-12-16 16:21:15,379 p=382940 u=root n=ansible INFO| Container confirmed 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| Using module file /etc/ansible/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| Pipelining is enabled. 2025-12-16 16:21:15,533 p=382940 u=root n=ansible INFO| <infra1> ESTABLISH SSH CONNECTION FOR USER: root 2025-12-16 16:21:15,534 p=382940 u=root n=ansible INFO| <infra1> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=300 -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="root"' -o ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ServerAliveInterval=64 -o ServerAliveCountMax=1024 -o Compression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no -o ForwardAgent=yes -T -o 'ControlPath="/root/.ansible/cp/0fbb4d5943"' infra1 'sudo lxc-attach --clear-env --name infra1-repo-container-0b24c04d -- su - root -c '"'"'/bin/sh -c '"'"'"'"'"'"'"'"'/usr/bin/python3.12 && sleep 0'"'"'"'"'"'"'"'"''"'"'' 2025-12-16 16:21:19,534 p=382940 u=root n=ansible INFO| <infra1> (1, b'\n{"changed": false, "rc": 1, "failed": true, "msg": "peer probe: failed: Probe returned with Transport endpoint is not connected\\n", "invocation": {"module_args": {"nodes": ["infra1-repo-container-0b24c04d", "infra2-repo-container-8419857e", "infra3-repo-container-8432350f"], "state": "present", "force": null}}}\n', b"OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files\r\ndebug1: /etc/ssh/ssh_config line 21: Applying options for *\r\ndebug1: auto-mux: Trying existing master at '/root/.ansible/cp/0fbb4d5943'\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 386307\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\n/tmp/ansible_gluster.gluster.gluster_peer_payload_cd62ayz2/ansible_gluster.gluster.gluster_peer_payload.zip/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py:173: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.\ndebug3: mux_client_read_packet_timeout: read header failed: Broken pipe\r\ndebug2: Received exit status from master 1\r\n") 2025-12-16 16:21:19,534 p=382940 u=root n=ansible INFO| <infra1> Failed to connect to the host via ssh: OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: auto-mux: Trying existing master at '/root/.ansible/cp/0fbb4d5943' debug2: fd 3 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 0 remote debug3: mux_client_request_session: entering debug3: mux_client_request_alive: entering debug3: mux_client_request_alive: done pid = 386307 debug3: mux_client_request_session: session request sent debug1: mux_client_request_session: master session id: 2 /tmp/ansible_gluster.gluster.gluster_peer_payload_cd62ayz2/ansible_gluster.gluster.gluster_peer_payload.zip/ansible_collections/gluster/gluster/plugins/modules/gluster_peer.py:173: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. debug3: mux_client_read_packet_timeout: read header failed: Broken pipe debug2: Received exit status from master 1 2025-12-16 16:21:19,539 p=382940 u=root n=ansible INFO| fatal: [infra1-repo-container-0b24c04d]: FAILED! => changed: false invocation: module_args: force: null nodes: - infra1-repo-container-0b24c04d - infra2-repo-container-8419857e - infra3-repo-container-8432350f state: present msg: |- peer probe: failed: Probe returned with Transport endpoint is not connected rc: 1 BR, Frank

1 0

[blazar] Extending the payload of a notification, to send the entire lease data
by NITIN GUPTA 16 Dec '25

16 Dec '25

Hello Blazar Team, May I have the following change reviewed, for extending the payload of a notification, to send the entire lease data: *https://review.opendev.org/c/openstack/blazar/+/965448 <https://review.opendev.org/c/openstack/blazar/+/965448>* Looking for your feedback as soon as possible. Best regards. -- NITIN GUPTA

2 9

[neutron] Bug deputy report for week of December 8th
by Brian Haley 15 Dec '25

15 Dec '25

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2134504 - Wrong neutron:host_id in LSP external_ids after live migration - https://review.opendev.org/c/openstack/neutron/+/970564 Medium ------ * https://bugs.launchpad.net/neutron/+bug/2134387 - The is_default flag cannot be modified for external networks - https://review.opendev.org/c/openstack/neutron/+/970204 * https://bugs.launchpad.net/neutron/+bug/2134703 - [OVN] `update_lrouter_ports_ext_ids_name_prefix` should provide the Neutron DB port in `_gen_router_port_ext_ids` call - https://review.opendev.org/c/openstack/neutron/+/970644 Low --- * None Invalid ------- * https://bugs.launchpad.net/neutron/+bug/2134388 - auto allocate topology fails when there is only a single external network - Could no longer reproduce Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2134606 - [RFE] Add an API that returns a list of available IPs in a network - Asked for more information based on the change already proposed for network-ip-availabilities additions https://review.opendev.org/c/openstack/neutron/+/965083 - Not sure this is useful, will ask at meeting * https://bugs.launchpad.net/neutron/+bug/2135228 - [RFE] Add support for local sink in tap mirror - Asked Miro to add to future Driver's agenda

1 0