December 2025 - openstack-discuss

[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
by Sharath Ck 05 Jan '26

05 Jan '26

Hi, I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed? Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response. P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked. user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true Regards, Sharath

3 2

need help in managing production openstack cluster
by Tarun 31 Dec '25

31 Dec '25

Hi, I am migrating from VMware to Openstack 2025.2 Please help me to validate my production cluster to avoid any future issue Thanks Tarun

3 3

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

30 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? Openstack version: 2023.1 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."

3 2

[nova] How to use $aggregates with JsonFilter
by Andy Speagle 30 Dec '25

30 Dec '25

Hey Team, I'm trying to use scheduler hints using the JsonFilter that involve host aggregates. Based on the documentation and my quick perusal of the scheduler's HostState class... it seems like $aggregates are populated there for usage, but I can't seem to find the right magick to make a json query work to schedule an instance on a host that belongs to a specific aggregate based on simply the name of the aggregate... or perhaps metadata contained within. I think my lack of understanding of the structure of the $aggregates list in the scheduler's HostState class is tripping me up. Does anyone have any insight into this?... Thanks. -- Andy Speagle

2 12

[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 30 Dec '25

30 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 24 Dec '25

24 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 5