December 2025 - openstack-discuss

[kolla] Cancelling weekly meetings on 24th and 31st of December 2025
by Michał Nasiadka 15 Dec '25

15 Dec '25

Hello Cancelling weekly meetings on 24th and 31st of December for obvious reasons The first meeting in 2026 will be on 7th of January Cheers, Michal

1 0

[freezer] Poll for regular IRC meeting time
by Dmitriy Rabotyagov 15 Dec '25

15 Dec '25

Hi everyone! We have decided to re-initiate a regular IRC meeting for the Freezer project to sync on development and let interested parties to step in and be in the loop of project development. In order to select a suitable time for such meeting for everyone currently interested, I have created a poll, you pay find via the link [1] The poll is open until Monday, December 15. If you are interested in the project and want to take part in meetings - feel free to vote on the timing! I have included as many time periods as possible to ensure we can find a suitable one for everyone. Also please ignore specific dates in the poll - we intend to make a meeting on a weekly basis, so only days of the week do matter there. [1] https://beta.framadate.org/polls/365ef8fa4574a9190ec0

2 2

[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
by Sharath Ck 15 Dec '25

15 Dec '25

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

2 1

[docs] Rate limiting (?) on docs.openstack.org causing link checks to break
by Florian Haas 15 Dec '25

15 Dec '25

Hello everyone, here's something of a meta-issue that's been bothering me for a while, and I wonder if we can find a solution or a workaround. Our public documentation at docs.cleura.cloud naturally has cross-references to docs.openstack.org. To make sure that our documentation remains current, the CI/CD build for our docs includes an external link checker.[1] That way, if external documentation paths change or go away, we get notified of a build failure, and this enables us to fix or update our docs. Unfortunately, this results in random and intermittent errors like this: Real URL https://docs.openstack.org/keystone/ Check time 2.759 seconds Size 251B Result Error: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) The Keystone docs URL is just an example; this sort of error happens all across the docs. Of the scores of docs.openstack.org links we check, it's usually just one that breaks, but it's always a different one. Kicking the pipeline and rerunning the same link check often "fixes" things, sometimes it doesn't, sometimes it breaks with a different link. I surmise that this is caused by a rate limit applicable on docs.openstack.org. I would understand why such a rate limit exists, so I am not suggesting to remove it, but right now I'm at my wit's end and I'm close to adding docs.openstack.org to the ignore regex in our linkchecker configuration. But I really don't *want* to do that because I'd quite prefer for our docs to contain good cross-references, and so I'm interested in keeping docs.o.o included in the link liveness check. I'm guessing others have run into this issue. If anyone has solved it in a clever way, I'd be grateful for suggestions. Thanks! Cheers, Florian [1] https://linkchecker.github.io/linkchecker/

2 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-15)
by Goutham Pacha Ravi 14 Dec '25

14 Dec '25

Hello Stackers, We're fifteen weeks away from the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. We're almost at the end of the calendar year, and many community members are taking a well-deserved break during this holiday season observed around the world. The OpenStack Technical Committee did not merge any significant changes in the past week. There's been some more progress on the cleanup effort we embarked on concerning the Monasca project and the governance-sigs repository. Ian Y Choi (ianychoi) and Slawek Kaplonski (slaweq) have graciously agreed to continue as OpenStack's election officials. They're assisted by Tony Breeds (tonyb) who will be the TC liaison. They've begun working on the combined PTL and TC elections that will be conducted in February. We'll share more details about this as they are finalized. === Weekly Meeting === The last meeting of the OpenStack Technical Committee occurred on December 9th, 2025, over the #openstack-tc IRC channel on OFTC [2]. At the meeting, we resolved pending some governance-website patches and established a plan to update the Technical Vision document [3] through brainstorming on an Etherpad. We also discussed the idea of requesting a deadline extension to propose user survey modifications [4]. The team felt that extending the deadline beyond M-2 will allow for input from project teams. We acknowledged the plan to delete unmaintained branches through Yoga [5], with a consensus leaning toward also dropping Zed. Clarification was sought from the "openstack-unmaintained-core" team regarding the "opt-in" maintenance model for newer branches. We noted that Ceph Tentacle is now being tested with DevStack. Additionally, Michal Nasiadka (mnasiadka) is exploring a fix to get an x86-v3 version of OVS to be installed on AlmaLinux while we pursue a packaging fix with AlmaLinux maintainers. This is a must-have because AlmaLinux provides us a good chance of testing OpenStack with an RPM-based distro across most of our cloud providers that have older hardware. The next meeting of the TC will be on Tuesday, December 16th, 2025, at 0800 UTC. Please note this new APAC-friendly time slot. We're gathering the community's interest in a once-monthly meeting in this time slot. Please participate if you're able to. You can find the meeting's agenda and other details on its wiki page [6]. The TC decided to cancel the meetings previously scheduled for December 23rd, 2025, and December 30th, in observance of the holidays. === Governance Proposals === ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - Alter public cloud SIG chair | https://review.opendev.org/c/openstack/governance/+/969371 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2025-12-16: Twelve Clouds of Christmas: https://www.meetup.com/openinfra-austin/events/312269596 - 2026-01-08: 2026.1 Milestone 2 - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ 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] TC Meeting IRC Log, Dec 9 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-09-17.02.html [3] Vision for OpenStack Clouds: https://governance.openstack.org/tc/reference/technical-vision.html [4] OpenStack 2025 User Survey Feedback: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] Unmaintained branch cleanup: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Dec 16 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Kolla-ansible Openstack deployment failed in nova-compute task
by ldemarco＠sinthera.com 12 Dec '25

12 Dec '25

Hi guys, In my first openstack deploy I facing an error in deployment phase. The bootstrap-servers phase and the prechecks phase working fine but the deploy phase stop to work in nova-compute task deployment with the following error [ERROR]: Task failed: Action failed. Origin: /root/kolla-venv/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml:24:7 22 expected_compute_service_hosts: "{{ virt_compute_service_hosts + ironic_compute_service_hosts }}" 23 block: 24 - name: Waiting for nova-compute services to register themselves looking for the nova-compute docker logs I found this event ERROR MissingRequiredSource: /var/lib/kolla/config_files/ceph.client.cinder.keyring file is not found I would you like to point out that the ceph keyring are created and copied to /etc/koll/config/nova in deployment host and /etc/ceph in all openstack host. Some one could help me for fix the issue ? Regards Luca

4 4

migrate ovs to ovn
by Eduardo Morais 11 Dec '25

11 Dec '25

Hey, good afternoon. My name is Eduardo and I’m new to OpenStack. At my job I have a task to migrate OVS to OVN, and I was able to do that, but I have a small question about a problem I'm facing after restarting my environment. When I restart my testing VM and try again, after the migration I get an error message in the Neutron logs about a duplicate entry. The message says that OVN is trying to insert information into the providerresourceassociations table, but the table already has that information and OpenStack works with it. However, after the restart, OpenStack crashes. To make it work again, I have to manually delete the existing entry so the new one can be inserted, and after doing that the problem does not happen anymore, send now for the correct mail, i think.

2 2

[neutron] Drivers meeting canceled Friday, December 12th
by Brian Haley 11 Dec '25

11 Dec '25

Hello Neutrinos: I am going to cancel Friday's Drivers meeting as I will be out the rest of the week. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[neutron] Neutron L3 HA Issue: Packet Loss and Route Flapping After Restarting openvswitch-vswitchd on Active Controller
by soheil.bakan＠gmail.com 11 Dec '25

11 Dec '25

Hi OpenStack Community, I am experiencing an issue in a 3-controller HA OpenStack environment related to Neutron L3 HA and Open vSwitch. I would appreciate your guidance or any insights. ### Environment - OpenStack version: 2025.1 - 3 controller nodes with HA setup (kolla-ansible) - Neutron L3 HA enabed - OVS + Keepalived (VRRP) - The router’s VRRP master role is currently on one controller - All controllers share the same external/provider network setup ### Issue Description When I restart the `openvswitch-vswitchd` service on the controller node that currently holds the VRRP Master for an HA router: The following problems occur: 1. ICMP traffic (ping) drops for several minutes. 2. The router’s default route begins to bounce between the other two or three controllers. 3. The VRRP master does not stabilize quickly; it keeps flipping between the remaining controllers. 4. As a result, I see packet loss and routing instability for several seconds. ### What I expect Ideally, when `openvswitch-vswitchd` restarts on the master controller: - VRRP should quickly fail over to one of the standby controllers routers - The default route should converge and remain stable - There should be no (or minimal) packet loss I should also say what when i restart neutron_l3_agent or in some cases openvswitch_db issue goes away ### Additional Information If needed, I can share: - Logs from OVS, neutron-l3-agent Thanks in advance for your support. Please let me know if more information is needed. best regards, soheil

3 2

[octavia] Weekly Octavia IRC meeting cancelled until January 7th
by Michael Johnson 10 Dec '25

10 Dec '25

Hello everyone, With the holiday season occurring in various parts of the world, we decided at today's meeting that we will cancel the weekly IRC meeting until January 7th, 2026. I look forward to chatting with you all in the new year! Michael

1 0