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

[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]Live-resize feature
by Nguyễn Hữu Khôi 23 Oct '25

23 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

2 1

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

23 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 1

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

23 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 2

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

22 Oct '25

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

4 13

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

22 Oct '25

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

2 1

[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

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

22 Oct '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 0

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

21 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

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

21 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 0

[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

[octavia] Octavia weekly IRC meeting cancelled 10/22
by Michael Johnson 20 Oct '25

20 Oct '25

As discussed at last week's meeting, we are cancelling this week's Octavia IRC meeting. We will see you at the PTG! Michael

1 0

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

20 Oct '25

Hello Stackers, Over the weekend, the OpenInfra Summit in Paris-Saclay wrapped up. From what I heard, it was a successful event with a lot to unpack for the entire community. We'll discuss the summit over trip reports and activity across and within project teams over the coming weeks. We're twenty-three weeks away from the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Next week, the OpenStack community will be participating in the OpenInfra Virtual Project Teams Gathering (PTG). Project teams are grooming discussion topics on Etherpads [2]. The OpenStack Technical Committee will be meeting alongside project teams [3], and we'll kick off discussions as we've usually done by meeting with project maintainers. All project team leads, DPL liaisons, and core maintainers are invited to attend, and brainstorm community-wide concerns during this time slot. This event will be held at 1600 UTC on Tuesday, October 28th, 2025. Please see the PTG website for the call information, and better yet, pop into the #openinfra-events IRC channel on OFTC for real-time updates from all project discussions throughout the week. If you haven't already registered for the event, please do so [4]. This past week was a busy week for the community and the OpenStack Technical Committee. The "ironic-inspector" repositories were removed, and all the functionality provided has long been integrated into Ironic. Michał Nasiadka (mnasiadka) volunteered to be the TC liaison for the Requirements and Release Management teams. The TC also marked the Vitrage and Venus project teams as "inactive" [5]. These project teams need help. If you're a maintainer, contributor, or user, please help us re-form the project teams by determining project leadership and fixing up any failing CI jobs. All deliverables associated with these project teams will be dropped from the 2026.1 "Gazpacho" release cycle. If activity does not resume, we'll retire the deliverables and the respective project teams in the 2026.2 release cycle. This week, the TC will begin our first monthly meeting at an APAC-friendly time! As a globally distributed community, our preferred mantra of communication is asynchronous; however, once in a while, sync meetings help us make progress, and we'll try to cater to as many different timezones as possible. For now, on every third Tuesday of the month, we'll meet at 0800 UTC (instead of 1700 UTC) in the #openstack-tc channel on OFTC. At the same time, we'll be stopping our Video + IRC meeting for the rest of this release development cycle. Please download the meeting's ICS file and update your calendars [6]. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee occurred on October 14th, 2025 [7]. The TC discussed several outstanding governance changes and gathered the roll call votes needed to mark Vitrage and Venus project teams inactive. We reiterated that the proposal to retire the Monasca project is still pending, but a current maintainer needs assistance with the release process, and Elod Illes (elodilles) would walk them through it. Michał Nasiadka (mnasiadka) volunteered to be the TC liaison for the Requirements and Release Management project teams. The TC agreed to sunset scheduled video meetings, opting to bring them back only on an ad-hoc basis due to lack of interest. The remaining portion of the meeting focused on establishing a new, more EU/APAC-friendly meeting time. We decided on doing this monthly on the third Tuesday at 08:00–09:00 UTC, replacing the regular 17:00 UTC slot for that day. We also called for topics for the upcoming PTG (Project Team Gathering) [3] and briefly reviewed the runtime and job changes for the Gazpacho release, which includes making the Python 3.13 job voting, creating a non-voting Python 3.14 job, and fixing up the grenade templates [8]. The next meeting of the TC is on October 21st, 2025, at 0800 UTC. This meeting will be hosted in the #openstack-tc channel on OFTC, and mnasiadka will be chairing it. Please find the agenda on the meeting's wiki page [9]. Please chime in and say hi. I do hope this new meeting slot is feasible for contributors in the Eastern Hemisphere. Do remember, you can always edit the wiki and propose new meeting topics. === Governance Proposals === ==== Merged ==== - Update TC liaisons for Freezer and Oslo | https://review.opendev.org/c/openstack/governance/+/964257 - Retire ironic-inspector from bare metal program | https://review.opendev.org/c/openstack/governance/+/963470 - Mark Vitrage project team inactive | https://review.opendev.org/c/openstack/governance/+/963227 - Mark Venus project team inactive | https://review.opendev.org/c/openstack/governance/+/963228 - Propose mnasiadka as tc-liaison for Requirements and Release Management | https://review.opendev.org/c/openstack/governance/+/963989 ==== Open For Review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-10-22: OpenInfra Meetup, Jakarta Selatan: https://www.meetup.com/openinfraid/events/31140538 - 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/ === How to Contact the TC === You can reach the TC in several ways: 1. Email: send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. 3. Join us at our weekly meeting: The Technical Committee meets every Tuesday at 1700 UTC, except the third Tuesday of the month, when we meet at 0800 UTC [9]. 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] Register to attend the OpenInfra PTG: https://ptg.openinfra.org/ [5] Inactive project teams: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [6] Download the TC meeting ICS: https://meetings.opendev.org/#Technical_Committee_Meeting [7] TC Meeting IRC Log, Oct 14th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-10-14-17.00.html [8] 2026.1 runtime test changes: https://review.opendev.org/q/hashtag:%222026-1-runtime-update%22 [9] TC Meeting Agenda, Oct 21st 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[PTG] Glance cross-project sessions with Cinder/Nova
by Cyril Roelandt 20 Oct '25

20 Oct '25

Hello, We would like to host two cross-project sessions regarding the following topics: - Image encryption and disk format enforcement[1]: this has implicatoins for both Nova and Cinder. This should probably be a one hour session. - Make multiattach workflow compatible with multiple glance workers: this is related to both Cinder and Glance. This could be a half hour or full hour session, depending on what Rajat has in mind. Glance is very flexible with its scheduling: we will be busy during the eventlet session on Tuesday between 15:00 UTC and 16:00 UTC, otherwise we're pretty much free every day between 13:00 UTC and 17:00 UTC. Ideally we would host these sessions on Wednesday or Thursday. What would work for members of the Nova and Cinder teams? On behalf of the Glance team, Cyril Roelandt [1] https://etherpad.opendev.org/p/2026.1-ptg-glance-planning#L128 [2] https://etherpad.opendev.org/p/2026.1-ptg-glance-planning#L140

1 0

[Ironic] Outreachy - Starting work on Bug #2072349: Rewrite page headings
by abhi pc 20 Oct '25

20 Oct '25

Hello Ironic Team and Documentation folks, I am an Outreachy applicant and I would like to take on Bug #2072349, "Rewrite page headings," as my first contribution. I understand this task involves applying the documentation style rules (gerunds for tasks, labels for reference, etc.) and will be a site-wide change. *Could someone please confirm if this bug is still active and suitable for an Outreachy applicant to start on?* I am planning to start by reviewing the documentation structure in the doc/source/ directory and will submit the changes in a series of small, logical patches. Thank you for your guidance! Abhijith P C

1 0

[PTG] #eventlet-removal: Upcoming PTG session
by Herve Beraud 20 Oct '25

20 Oct '25

Hello folks, FYI, there is an Eventlet removal session planned at the upcoming PTG. The session will be a one hour discussion scheduled on Tuesday 28th at 15:00 UTC. Here is the etherpad link: https://etherpad.opendev.org/p/oct2025-ptg-eventlet Feel free to add topics. Best regards, -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[kolla][kolla-ansible] Contributing to a Gerrit change not owned by me
by sarah.kh09＠gmail.com 19 Oct '25

19 Oct '25

Hi everyone, I have a question about contributing to an existing change in Gerrit. Is it possible to propose additional commits or modifications to a change that I do not own (i.e., a change created by another contributor), so that my update will appear as a new patch set on the same change, not as a separate one? If yes, what’s the recommended workflow or best practice to do this in the Kolla Ansible project? Also, do I just need the approval or agreement of the change owner before pushing my patch set, or are there any other formal steps required? Thanks in advance for your guidance!

3 4

[nova][sdk] Compute host query filter on list servers
by Winicius Allan 17 Oct '25

17 Oct '25

When building a script that utilizes openstacksdk, I encountered a problem while filtering servers by compute host. According to the documentation[1], I need to refer to the Compute API to find the available query parameters. On the API docs, the proper query param is just `host` instead of compute_host. I raised a discussion in[2]. I'd like to know the maintainers' opinions on this, and the decisions made. [1] https://docs.openstack.org/openstacksdk/latest/user/proxies/compute.html#se… [2] https://bugs.launchpad.net/openstacksdk/+bug/2101016

1 0

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

17 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

1 0

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

17 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

1 0

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

17 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

1 0

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

17 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

1 0

[neutron] Drivers meeting canceled next two weeks
by Brian Haley 16 Oct '25

16 Oct '25

Hello Neutrinos: I am going to cancel the next two Drivers meeting as there are no topics and the PTG is coming up - please just add things to the etherpad so we can discuss there [0]. And just a reminder there are still open specs that need updates and/or review, list is at [1]. Have a nice weekend! -Brian [0] https://etherpad.opendev.org/p/oct2025-ptg-neutron [1] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[neutron][ovn][ovn-bgp-agent] Backports and reviews
by Mohammed Naser 16 Oct '25

16 Oct '25

Hi team, We've pushed out several fixes that include trivial bug fix backports and a bigger rework of the driver ecosystem which have sat dormant for a few months now: - https://review.opendev.org/c/openstack/ovn-bgp-agent/+/947151 - https://review.opendev.org/c/openstack/ovn-bgp-agent/+/947152 - https://review.opendev.org/c/openstack/ovn-bgp-agent/+/947153 These ones have sat so long that they've hit merge conflicts: - https://review.opendev.org/c/openstack/ovn-bgp-agent/+/944300 - https://review.opendev.org/c/openstack/ovn-bgp-agent/+/937457 We've resorted to downstream and they've been working in production for a long time, however, we really want to make sure the ecosystem in OpenStack doesn't become a downstream-best one. Thanks Mohammed

2 1

[horizon] add microversion support for Nova live migration
by Mohammed Naser 16 Oct '25

16 Oct '25

Hi team, We've pushed this change out for nearly a month with no reviews, I would like to please have the Horizon team have a look at this change. https://review.opendev.org/c/openstack/horizon/+/961099 Thank you, Mohammed

1 0

[neutron] Next two weeks CI meeting cancelled
by Yatin Karel 16 Oct '25

16 Oct '25

Hello Neutron Team !! As discussed in the last CI meeting I will not be around upcoming Monday, so cancelling the meeting. Also proposing to cancel the follow up week as that's PTG week. So we will have our next CI meeting on 03rd November. -- Thanks and Regards Yatin Karel

1 0

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

15 Oct '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."

3 2

How to set admin password during server create but not using user-data file
by Ahmad Milad Pour 15 Oct '25

15 Oct '25

Hello there, This is how I download an ubuntu cloud image: wget -c https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.i… -O ~/noble-server-cloudimg-amd64.img virt-customize -a noble-server-cloudimg-amd64.img \ --timezone Asia/Tehran \ --root-password password:q \ --run-command 'sed -i "s/^disable_root.*/disable_root: false/" /etc/cloud/cloud.cfg' \ --run-command 'grep -q "^ssh_pwauth:" /etc/cloud/cloud.cfg && sed -i "s/^ssh_pwauth:.*/ssh_pwauth: true/" /etc/cloud/cloud.cfg || echo "ssh_pwauth: true" >> /etc/cloud/cloud.cfg' \ --run-command 'printf "PasswordAuthentication yes\nPermitRootLogin yes\n" > /etc/ssh/sshd_config.d/99-allow-root.conf' \ --run-command "sed -e 's/^[# ]*PasswordAuthentication.*/PasswordAuthentication yes/g' -i /etc/ssh/sshd_config || true" \ --run-command "sed -e 's/^[# ]*PermitRootLogin.*/PermitRootLogin yes/g' -i /etc/ssh/sshd_config || true" \ --run-command 'systemctl enable ssh || systemctl enable sshd' \ --run-command 'systemctl disable systemd-networkd-wait-online.service' openstack image create --file ~/noble-server-cloudimg-amd64.img --disk-format qcow2 --container-format bare --public --property os_distro=ubuntu --property hw_qemu_guest_agent=yes "Ubuntu 24" || true rm -f noble-server-cloudimg-amd64.img cat <<EOF > /root/userdata.txt #cloud-config chpasswd: list: | root:q expire: False ssh_pwauth: True cmd: - systemctl disable systemd-networkd-wait-online.service EOF openstack server create --image "Ubuntu 24" --flavor first --network public_network --config-drive True ahmad --password 'ahmad' This is how I create image. I'm going to find a way if possible, to set the admin password during the "server create". Currently the root login is only possible with password "q". The "ahmad" is not working. I know I can change it via user-data file (I intentionally added there but not using it), but the question is can I set the password during the server create? I tried to use "virt-customize --install qemu-guest-agent", but the virt-customize has no network, so no installation. I also know I can do this: 1. create server 2. do whatever I want (install guest agent, etc) 3. create snapshot 4. create server from that snapshot But the issue is it's not automatic (I should manually login to do the modification) and its size is much more than the cloud image. Like, from 500 megabytes which is cloud image, goes around 3 gigabytes which is the snapshot. Any ways to reach what I'm looking for? Or even any better ways to do that? Regards, Ahmad

5 12

[Skyline] Core Reviewer Nomination - Reet Srivastava (reetsrivastava)
by Reet Srivastava 14 Oct '25

14 Oct '25

Hi team, I am writing to nominate myself(Reet Srivastava) as a contributor and core reviewer for the skyline project. Over the past three months I have made significant contributions to the Skyline project. Some of my contributions are : feat: Add configurable user default domain for login (959304) · Gerrit Code Review<https://review.opendev.org/c/openstack/skyline-apiserver/+/959304> feat:adds barbican panel(named Key-Manager) (958515) · Gerrit Code Review<https://review.opendev.org/c/openstack/skyline-console/+/958515> feat: Add Unrescue feature to nova instance actions (961359) · Gerrit Code Review<https://review.opendev.org/c/openstack/skyline-console/+/961359> feat: Make default user domain configurable and improve username handling (959284) · Gerrit Code Review<https://review.opendev.org/c/openstack/skyline-console/+/959284> (In Progress) I believe I can help uphold the quality of our codebase and support contributors in their development efforts. I’d be grateful for your feedback and support regarding this nomination. Thanks for your time and consideration. Best Regards, Reet Srivastava Gerrit Username - reetsrivastava

3 2

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

14 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 2

Yubikey SSH public key support in keypairs
by Ivan Marton 14 Oct '25

14 Oct '25

Dear Openstack community, I'm wondering if there are any plans to support sk-ssh-ed25519(a)openssh.com SSH public key formats for the keypairs endpoint. I did not find in the public documentation any explicit information about supported SSH public keys, but according to my experiences the mentioned format is not accepted. Did I miss something? Is it supported in any recent versions? Is it on the roadmap? Thank you all for any reply! Best regards, Ivan Marton

10 22

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

14 Oct '25

Hello openstack Community, I am using Ceph as the backend storage for OpenStack and deployed it via ceph-ansible.I enabled Jaeger tracing on Ceph cluster using: - Global Ceph config: ceph config set global jaeger_tracing_enable true - Jaeger Docker all-in-one docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -e COLLECTOR_OTLP_ENABLED=true --network host -p 6799:6799/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 4317:4317-p 4318:4318 -p 14250:14250 -p 14268:14268 -p 14269:14269 -p 9411:9411 jaegertracing/all-in-one:1.27 --processor.jaeger-compact.server-host-port=6799 Issue: - Only OSD traces appear with limitation traces(`enqueue_op`, `op-request-created`) - No traces from MON, MGR, or RGW Questions: 1. Is this the correct process for enabling tracing? 2. How can I capture traces for MON, MGR, RGW? 3. How can I see all OSD operations? 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

[horizon] Help review the patch https://review.opendev.org/c/openstack/horizon/+/961099
by Dong Ma 14 Oct '25

14 Oct '25

Hi, We’ve submitted a patch (https://review.opendev.org/c/openstack/horizon/+/961099) adding microversion support for Nova live migration. Appreciate any reviews from the core team so we can get it merged soon. Thanks, -- Dong Ma — vexxhost

1 0

How to set admin password during server create but not using user-data file
by Ahmad Milad Pour 14 Oct '25

14 Oct '25

Hello there, This is how I download an ubuntu cloud image: wget -c https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.i… -O ~/noble-server-cloudimg-amd64.img virt-customize -a noble-server-cloudimg-amd64.img \ --timezone Asia/Tehran \ --root-password password:q \ --run-command 'sed -i "s/^disable_root.*/disable_root: false/" /etc/cloud/cloud.cfg' \ --run-command 'grep -q "^ssh_pwauth:" /etc/cloud/cloud.cfg && sed -i "s/^ssh_pwauth:.*/ssh_pwauth: true/" /etc/cloud/cloud.cfg || echo "ssh_pwauth: true" >> /etc/cloud/cloud.cfg' \ --run-command 'printf "PasswordAuthentication yes\nPermitRootLogin yes\n" > /etc/ssh/sshd_config.d/99-allow-root.conf' \ --run-command "sed -e 's/^[# ]*PasswordAuthentication.*/PasswordAuthentication yes/g' -i /etc/ssh/sshd_config || true" \ --run-command "sed -e 's/^[# ]*PermitRootLogin.*/PermitRootLogin yes/g' -i /etc/ssh/sshd_config || true" \ --run-command 'systemctl enable ssh || systemctl enable sshd' \ --run-command 'systemctl disable systemd-networkd-wait-online.service' openstack image create --file ~/noble-server-cloudimg-amd64.img --disk-format qcow2 --container-format bare --public --property os_distro=ubuntu --property hw_qemu_guest_agent=yes "Ubuntu 24" || true rm -f noble-server-cloudimg-amd64.img cat <<EOF > /root/userdata.txt #cloud-config chpasswd: list: | root:q expire: False ssh_pwauth: True cmd: - systemctl disable systemd-networkd-wait-online.service EOF openstack server create --image "Ubuntu 24" --flavor first --network public_network --config-drive True ahmad --password 'ahmad' This is how I create image. I'm going to find a way if possible, to set the admin password during the "server create". Currently the root login is only possible with password "q". The "ahmad" is not working. I know I can change it via user-data file (I intentionally added there but not using it), but the question is can I set the password during the server create? I tried to use "virt-customize --install qemu-guest-agent", but the virt-customize has no network, so no installation. I also know I can do this: 1. create server 2. do whatever I want (install guest agent, etc) 3. create snapshot 4. create server from that snapshot But the issue is it's not automatic (I should manually login to do the modification) and its size is much more than the cloud image. Like, from 500 megabytes which is cloud image, goes around 3 gigabytes which is the snapshot. Any ways to reach what I'm looking for? Or even any better ways to do that? Regards, Ahmad

1 0

[ovn][wallaby][migration] Live migration more than 10s switchover
by Kamil Madac 14 Oct '25

14 Oct '25

Hello community, We are running a Wallaby TripleO installation with OVN networking. During live migration, we’re experiencing a connectivity outage lasting between *10 and 40 seconds* on the provider network to which the migrating VM is connected. I don’t see any errors in the ovn-controller, nova, or neutron logs. Is this behavior normal for the Wallaby release? We don’t see this issue in our Kolla-Ansible deployment running OpenStack 2024.2. I found that OVN multi-chassis port bindings were not yet implemented in Wallaby, but still — more than 10 seconds of downtime during live migration seems excessive. Has anyone observed similar behavior with older OpenStack releases, or is there any way to tune or optimize the switchover to reduce the outage duration? Thanks for any advice. Best regards, Kamil

1 0

[horizon] Help review the patch https://review.opendev.org/c/openstack/horizon/+/961099
by Dong Ma 13 Oct '25

13 Oct '25

Hi, We’ve submitted a patch (https://review.opendev.org/c/openstack/horizon/+/961099) adding microversion support for Nova live migration. Appreciate any reviews from the core team so we can get it merged soon. Thanks, -- Dong Ma — vexxhost

1 0

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

13 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>*

1 1

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

13 Oct '25

Hello Stackers, We're twenty-four weeks away from the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. In a couple of weeks, the community will be gathering to design and discuss features and bug fixes for this release [2]. PTLs and project liaisons are requested to finalize their project schedules for the PTG and strive to use the first two days solely for wider cross-project discussions. At the end of this week, a portion of our community will be participating in the OpenInfra Summit happening at the École Polytechnique Campus in Paris-Saclay, France [3]. There's a meet-and-greet session planned with the OpenStack Technical Committee on Sunday, October 19th starting at 17:05 UTC in the Becquerel room. If you're attending the summit, do try to add this to your calendar. During the past week, the TC didn't make any major governance updates. A few are currently undergoing community review. === Weekly Meeting === The last weekly meeting of the OpenStack TC occurred on October 7th, 2025 simultaneously over IRC [4] and video [5]. We had a small list of attendees and a short agenda. We noted that the governance changes to officially mark Venus and Vitrage as inactive are in progress. The retirement of Monasca is still held up, and the team is waiting for a response from a potential new maintainer. Discussions were held on the new APAC-friendly TC meeting slot, with the plan to review the poll results and schedule the first meeting shortly after the OpenStack Summit, likely on a monthly or bi-weekly cadence. I'll follow up with more details about this. We also discussed the need to refresh the TC Liaisons for several project teams (Freezer, Oslo, Release Management, and Requirements) and are seeking volunteers on the TC. We called for topics for the PTG. The TC will join project teams in analyzing the User Survey results [6]. The next meeting of the OpenStack Technical Committee will be hosted on OFTC's #openstack-tc channel on October 14th, 2025 at 1700 UTC. Please find the agenda for this meeting on the wiki [7]. I hope you're able to join us there. === Governance Proposals === ==== Merged ==== - Allow .gitignore in legacy repositories | https://review.opendev.org/c/openstack/governance/+/963867 - Retire metalsmith project from bare metal program | https://review.opendev.org/c/openstack/governance/+/958297 ==== Open For Review ==== - Mark Vitrage project-team inactive | https://review.opendev.org/c/openstack/governance/+/963227 - Mark Venus project-team inactive | https://review.opendev.org/c/openstack/governance/+/963228 - Retire ironic-inspector from bare metal program | https://review.opendev.org/c/openstack/governance/+/963470 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-22: OpenInfra Meetup, Jakarta Selatan: https://www.meetup.com/openinfraid/events/31140538 - 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) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenInfra Project Teams Gathering: https://ptg.openinfra.org/ [3] OpenInfra Summit: https://summit2025.openinfra.org/ [4] TC Meeting IRC Log, Oct 7th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-10-07-17.01.html [5] TC Meeting Video Recording, Oct 7th 2025: https://youtu.be/s_j3LPg-f1M [6] OpenStack User Survey: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, Oct 14th 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[glance] image upload fails "Unsupported Media Type", "Multiple formats detected: iso,gpt"
by Eugen Block 13 Oct '25

13 Oct '25

Good morning, after our recent upgrade to Epoxy we had troubles uploading images to Glance: openstack image create --disk-format raw --file .../opensuse/Leap-16.0-offline-installer-x86_64.install.iso --progress --public test-ebl [=============================>] 100% HttpException: 415: Client Error for url: http://controller.domain:9292/v2/images/e23d802e-d927-4f34-ae2d-1d6f54d6206…, Unsupported Media Type And in the logs this is reported: 2025-10-11 01:16:56.585 65675 ERROR glance.api.v2.image_data [None req-086ad005-a455-471a-bb0d-9dfe5e27eacf 89c5dcc8793d4867bae22d50e51e16b3 90c403f317ee47feb0dad58461e76fb1 - - default default] Multiple formats detected: iso,gpt: glance.common.exception.InvalidImageData: Multiple formats detected: iso,gpt This is the official openSUSE Leap 16 ISO file. For now I disabled the check by setting: [image_format] require_image_format_match = false The docs state that this is likely a bug: > Disabling this may be required in the case of false match (or > mismatch) issues, but those are bugs that should be filed and fixed. I tried a couple of different ISO files (Ubuntu, openSUSE, incl. older files), all fail with the same error. Uploading raw images seemed to work fine. ISOs are supported file formats according to the docs, could anyone shed some light on this? Thanks! Eugen

2 6

[neutron] Bug deputy Oct 6 - Oct 12
by Rodolfo Alonso Hernandez 13 Oct '25

13 Oct '25

Hello Neutrinos: This is the bug report from the last week (Oct 6 - Oct 12) High: * [VPNAAS] vpnaas AttributeError: 'dict' object has no attribute 'router' ( https://bugs.launchpad.net/neutron/+bug/2127169) Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/963493 * [VPNAAS] vpnaas no config update in ipsec.conf ( https://bugs.launchpad.net/neutron/+bug/2127166) Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/963490 * [VPNAAS] Libreswan config broken when used with new AEAD ciphers ( https://bugs.launchpad.net/neutron/+bug/2127159) Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/963489 * [VPNAAS] ovn-vpn-agent fails to delete vpn service ( https://bugs.launchpad.net/neutron/+bug/2127157) Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/963487 * OVN CI jobs on ironic are broken ( https://bugs.launchpad.net/neutron/+bug/2127038) Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/963390 (fixed). Medium: * ovn_dhcp4_global_options doesn't support keys with a list of values ( https://bugs.launchpad.net/neutron/+bug/2126923) Not assigned. Undecided: * Neutron not able to create external ports for virtual routers ( https://bugs.launchpad.net/neutron/+bug/2126913) Still deciding if this is a configuration issue. Regards.

1 0

Unable to create new instance while the computes are up
by Ahmad Milad Pour 13 Oct '25

13 Oct '25

Hello there, I asked the ChatGPT to help me to install the openstack on region, and to run a compute server. The ".sh" files are the installation. The "common_ask.sh" file is I run on both servers. The "region_ask.sh" is the file to install openstack and the region. The "compute_ask.sh" is the file to run the compute. The logs and errors are in the "region_details.txt" file. Would you please help me why the server I create has error and cannot be up? The way to create new instance is in the last lines of the "region_ask.sh" which is "openstack server create ...". Regards Ahmad

4 3

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

12 Oct '25

Hi team, Due to a holiday and most of the core members aren't join, I'm cancelling tomorrow's meeting. Regards, Yasufumi

1 0

[OpenStack Ansible] [Deployment] Networking design
by holywine＠outlook.com 12 Oct '25

12 Oct '25

Hello, I am trying to build a minimum usable production-level cloud with OpenStack Ansible following online reference. The idea it shoud be able to scale up without radical change afterwards. Online reference: https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/ openstack-ansible version: stable/2025.1 Target hosts (Ubuntu 24.04LTS): 1) Infra1: Controller 1 + networking 2) Infra2: Controller 2 3) Compute 1: Compute 1 + storage 1 4) Compute 2: Compute 2 + storage 2 Deploy host: dev-host (Ubuntu 24.04LTS) Network: Each sever has two network adapter, say enp11s0f0 and enp11s0f1 (different server may have different port name, en0 and en1 for short). Public IP (en1) : Infra1 - 10.2.46.70/24, fixed IP permanently assigned by provider. Infra2, Compute 1, Compute 2 - 10.2.46.XX/24, dynamic IP temporary assigned for SW installation Private IP (en0): Infra1: 172.29.236.11/22, VLAN 10 172.29.240.11/22, VLAN 30 Infra2: 172.29.236.12/22, VLAN 10 172.29.240.12/22, VLAN 30 Compute 1: 172.29.236.13/22, VLAN 10 172.29.240.13/22, VLAN 30 172.29.244.13/22, VLAN 20 Compute 2: 172.29.236.14/22, VLAN 10 172.29.240.14/22, VLAN 30 172.29.244.14/22, VLAN 20 VLAN 10 - management network VLAN 30 - tunnel network VLAN 20 - storage network Target: Since only Infra1:en1 is available with fixed public IP, It would be the only Internet connection without any port bonding. What have been done: 1) All ordinary IPs and VLANs setting (as above Network part) - The settings are verified and working (verified by ping and curl) 2) user_variables.yml haproxy_keepalived_external_vip_cidr: "10.2.46.70/24" haproxy_keepalived_internal_vip_cidr: "172.29.236.11/22" haproxy_keepalived_external_interface: enp11s0f1 haproxy_keepalived_internal_interface: br-mgmt 3) openstack_user_config.yml internal_lb_vip_address: 172.29.236.11 external_lb_vip_address: 10.2.46.70 Based on experiences as network engineer previously and a lot of readings from books and online guidance esp. the OpenStack Ansible deployment reference, I understand there should/could be something extra to be done. Can anybody please give me a clue on what else to be done or it is enough to make it working? Sorry for disturbing if any but netwoking seems to be the most complicated part for OpenStack deployment. The online examples are hard to be comprehend and customized. One small example: Ubuntu seems to be promoting netplan, while the examples are all with /etc/network/interfaces file (difficult to adapte with Ubuntu24.04). Thanks a lot for help in advance!

2 4

[release] Release countdown for week R-24
by Thierry Carrez 10 Oct '25

10 Oct '25

Welcome back to the release countdown emails! These will be sent at major points in the 2026.1 "Gazpacho" development cycle, which should conclude with a final release on April 1st, 2026 (not a joke). Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2026.1 "Gazpacho" development cycle, assessing Gazpacho community goals and approving Gazpacho specs. General Information ------------------- The 2026.1 "Gazpacho" development cycle will be a classic 26-week-long cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/gazpacho/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2025.2 "Flamingo" release are continued in 2026.1 "Gazpacho" with a similar release model. Upcoming Deadlines & Dates -------------------------- OpenInfra Summit Europe: October 17th-19th, 2025 OpenStack PTG (virtual): October 27th-31st, 2025 Gazpacho-1 milestone: November 13th, 2025 -- Thierry Carrez (ttx)

1 0

[neutron] Drivers meeting canceled Friday, October 10th
by Brian Haley 09 Oct '25

09 Oct '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as there are no topics and I will be out. At this point we should probably just add things to the PTG etherpad and discuss there [0]. Just a reminder there are still open specs that need updates and/or review, list is at [1]. Have a nice weekend! -Brian [0] https://etherpad.opendev.org/p/oct2025-ptg-neutron [1] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[PTLs] [OpenStack TC] Anonymized User Survey Feedback
by Jimmy McArthur 09 Oct '25

09 Oct '25

As you know each year we conduct an OpenStack User Survey. A big chunk of that survey data is dedicated to OpenStack projects, WGs, etc… I’d like to invite you all to review the anonymized feedback from 2025[1]. Please review not only for feedback, but to determine if you want to update your TC, PTL or WG questions. Additionally, if the TC can ensure that questions are up to date wrt to project or working group status. For example, we know the InteropWG has been disbanded as of this year, so we should probably remove those questions for 2026. We would like to have ALL reviews/requests in no later than December 1, 2025. If we do not hear from your project, we will assume you want no changes. If you have any questions, please let myself or Allison Price know. Cheers, Jimmy [1] https://docs.google.com/spreadsheets/d/1bte_k0R3_rVzFF9ND5zTZV0j9liXI1PxPNo…

2 2

[neutron] oslo.messaging and port notifications broadcast
by Thomas Goirand 08 Oct '25

08 Oct '25

Hi, Is it possible, with oslo.messaging, to have 3 daemons to get the Neutron port.{create,update,delete}.end notification events? I tried hard, but no mater how I do it, only one of my 3 daemons get the message. I'm about to add forwarding feature to the other 2 when one receives an event. Is there a better way? Cheers, Thomas Goirand (zigo)

5 12

[PTL][release][stable] 2024.1 Caracal transition to Unmaintained
by Elõd Illés 08 Oct '25

08 Oct '25

Hi teams, As 2025.2 Flamingo was released last week and we are in a less busy period, now is the good time to call your attention to the following: At the end of October 2024.1 Caracal is planned to transition to Unmaintained phase [1] (planned date: 2025-10-24). I have generated the list of the current *open* and *unreleased* changes in stable/2024.1 for every repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Caracal before moving stable/2024.1 branches to unmaintained/2024.1. Feel free to edit and extend these lists to track your team's progress! Note that the last hash on stable/2024.1 branch will be tagged ('2024.1-eom' tag) and transition patches will be generated soon. After the tagging and cutting unmaintained/2024.1 branch, the new unmaintained branch will be open to for bug fixes, but there won't be official releases for 2024.1 Caracal anymore. (You can get some information about the Unmaintained state on stable policy page [3]). *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/2024.1-caracal-final-release-before-eom [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla] Next two weekly meetings - 8th Oct and 15th Oct
by Michał Nasiadka 07 Oct '25

07 Oct '25

Hello, The next two weekly meetings for Kolla are cancelled: 8th Oct (today) - due to unavailability of key participants 15th Oct (next week) - due to OpenInfra Summit

1 0

[ptl][venus][tc] Need a PTL volunteer for OpenStack Venus project team
by Goutham Pacha Ravi 07 Oct '25

07 Oct '25

Hello Stackers, We're missing a Project Team Lead (PTL) for the OpenStack Venus project team for the "2026.1" (Gazpacho) release cycle. If you're interested, please let us know by proposing a PTL appointment (e.g. [1]). Thanks, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/governance/+/899781

1 2

[ptl][vitrage][tc] Need a PTL volunteer for OpenStack Vitrage project team
by Goutham Pacha Ravi 07 Oct '25

07 Oct '25

Hello Stackers, We're missing a Project Team Lead (PTL) for the OpenStack Vitrage project team for the "2026.1" (Gazpacho) release cycle. If you're interested, please let us know by proposing a PTL appointment (e.g. [1]). Thanks, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/governance/+/882139

1 2

[kolla][kolla-ansible] Managing Object Storage Backend via Kolla-Ansible
by Sara khosravi 07 Oct '25

07 Oct '25

Hello everyone, We are currently using Kolla-Ansible stable/2024.1 to manage our OpenStack deployment, including both core services and the Swift object storage backend. Our goal is to manage all OpenStack services, including object storage, through a unified lifecycle management tool. We understand that managing large volumes of data can affect the performance of other services. To address this, we've separated the data flow entry points that could become bottlenecks into dedicated host groups: a load balancer and a Swift proxy. Specifically, we've created two separate host groups: one for the secondary load balancer (which serves as the initial entry point) and another for the Swift proxy services. 🔹 Key Point 1: Decoupling Swift Traffic We’ve separated the Swift proxy nodes from the other OpenStack API services. This also means that the load balancer handling Swift traffic must be distinct from the main load balancer used for services like Nova, Glance, and Neutron. 🔹 Key Point 2: Keystone Endpoint Behavior Swift still registers with the existing Keystone service. Depending on the configuration: - If the second_loadbalancer is enabled, Keystone publishes the VIP (Virtual IP) of the secondary HAProxy as the Swift endpoint. - If it’s disabled, Keystone uses the direct API address of the Swift proxy node. 🔹 Key Point 3: Two Supported Configurations Kolla-Ansible supports two architecture models for Swift: Normal and Advanced. - Normal Configuration This is the default setup in stable/2024.1, where all OpenStack services, including Swift, share the same load balancer and traffic path. - Advanced Configuration This is recommended for large-scale deployments with heavy data volumes. In this setup, Swift traffic goes through a dedicated load balancer and proxy nodes, which reduces contention and improves performance. We’ve attached an architectural diagram to better illustrate the setup. We’d love to share this approach with the community and welcome any feedback or suggestions. Our goal is to make managing both compute and storage services within a single deployment framework as simple as possible. Thanks in advance for your insights!

3 3

[nova] limiting number of attached devices
by Pavlo Shchelokovskyy 07 Oct '25

07 Oct '25

Hi all, we've recently faced a peculiar issue with one of the users, namely: - fat VM with 100 cores - virtio-net multiqueue set up for the VM (`hw:vif_multiqueue_enabled`) - quite a number of NICs attached. On an attempt to attach yet another NIC (~20th), instance crashes with specific error message in the qemu log ``` qemu-system-x86_64: ../../accel/kvm/kvm-all.c:1754: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. ``` After debugging, we believe that what's happening is we are hitting an intrinsic limit of IRQs in a KVM guest ( `KVM_MAX_IRQ_ROUTES 4096` here https://github.com/torvalds/linux/blob/master/include/linux/kvm_host.h#L2175 ). With multiqueue and this number of vCPUs, each new NIC adds ~200 interrupts in the guest, so with some other system ones and some more devices already present, at some point, adding one more NIC overflows this current limit. In this particular case, the problem is exaggerated by the fact that what's requesting the new NIC attachment is some sort of CNI-like automation inside the guest, reacting on some external events (like another k8s node going down and pods being migrated). This got me thinking - should nova be able to somehow hard-limit the number of attached devices to a VM? I do not think nova should be "counting the IRQs" per se, as there are things outside that nova does not necessarily know (like what and how many actual devices a given qemu machine type creates inside the guest). But having some knob on a user side, for example a special metadata set on the instance, or at least an extra spec property for the flavor, could possibly suffice in this case. I'm eager to hear your thoughts on this, please chime in with any ideas on how to prevent such self-destructing instances :-) Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

1 0

[kolla][kolla-ansible] Managing Object Storage Backend via Kolla-Ansible
by Sara khosravi 07 Oct '25

07 Oct '25

Hello everyone, We’re currently using Kolla-Ansible stable/2024.1 to manage our OpenStack deployment, including both core services and the Swift object storage backend. aiming to manage both core OpenStack services and the object storage service through a unified lifecycle management tool. We understand that handling large volumes of data can impact the performance of other services. To mitigate this, we've separated the data path entry points that could become bottlenecks into dedicated and distinct host groups—load balancer and Swift proxy. Specifically, we've introduced two host groups: one for the secondary load balancer (serving as the initial entry gateway) and another for the Swift proxy services. 🔹 **Key Point 1:** We've decoupled the Swift proxy from other OpenStack API services. As a result, the load balancer for Swift must also be isolated from the main load balancer handling other APIs. 🔹 **Key Point 2:** The Swift service registers itself with the existing Keystone service. Depending on the configuration: - If `second_loadbalancer` is enabled, Keystone will expose the load balancer VIP as the endpoint for object storage. - If `second_loadbalancer` is disabled, Keystone will use the direct API address of the Swift proxy. We've attached an architectural diagram to illustrate the overall setup. We’d love to share this approach and welcome any feedback or suggestions from the community. Our broader goal is to eliminate the barriers to managing both storage and OpenStack services simultaneously within a single deployment and through a unified tool. Thanks in advance for your insights!

2 1

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

06 Oct '25

Hello Stackers, We're officially in the 2026.1 "Gazpacho" development cycle [1]. Congratulations on the successful and timely release of OpenStack's 32nd release: 2025.2 "Flamingo". For more information on the release, the OpenInfra Foundation staff have pieced together a release highlight on the OpenStack website [2], and project maintainers spoke about the release on OpenInfra Live [3] last week. In the past week, as our focus slowly began shifting between release boundaries, the OpenStack Technical Committee welcomed a new Vice-Chair, Michał Nasiadka (mnasiadka). We're exploring options for an alternate weekly meeting timing that could be friendly to our contributors in the Eastern Hemisphere. mnasiadka will be leading these meetings, while we still hope to continue a good cadence on our existing weekly meetings. I'll bring you more details about this change as we finalize the details. We're also actively planning sessions for the upcoming OpenInfra PTG. The OpenStack TC etherpad is available for you to propose topics [4]. Please feel free to add a topic along with your nick and timezone so we can coordinate a final schedule during the PTG week, avoiding as many conflicts as possible. In the past week, the TC appointed Felipe Reyes (freyes) as the PTL to the OpenStack Charms project [5]. We extended the "inactive" status of the Monasca team through the 2025.2 release cycle, and a decision on its retirement is imminent. There are similar proposals regarding other teams that had no PTL nominees in this past round of elections. === Weekly Meeting === The TC weekly meeting on September 30th 2025 [6] focused primarily on addressing leaderless projects and filling key TC roles. The committee proposed to mark both the Venus and Vitrage project teams as "inactive" and notify the openstack-discuss mailing list, as neither team has found a new Project Team Lead (PTL) so far. The Gerrit activity on both these projects has shown a slowdown, which could either mean maturity and stability, or lack of maintenance. Continuous integration system jobs are failing for some of the deliverables; therefore, they're not release-worthy for now. If maintenance and development activity does not resume over the 2026.1 release cycle, the deliverables will be retired. We discussed the need for TC liaisons to the Freezer, Oslo, Release Management, and Requirements projects. Sylvain Bauza (bauzas) and I will continue being the OpenStack VMT liaisons. We noted progress on the recent community engagement regarding Skyline's health and patch merging [7], and discussed plans to mentor one or more new core maintainers, and possibly hold a dedicated slot at the upcoming PTG (Project Team Gathering) to encourage further engagement. The TC is running an internal poll to find a preferred time slot and format (video vs. IRC) for future meetings, including a request for a slot that better suits EU and APAC time zones. The next meeting of the OpenStack TC is on October 7th 2025. This meeting will be hosted on Meetpad and IRC simultaneously. Please find the meeting's agenda and joining details in the wiki [8]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Add 2026.1 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/962614 - Extend Monasca's inactive state | https://review.opendev.org/c/openstack/governance/+/959392 - Appoint Felipe Reyes as PTL for OpenStack Charms | https://review.opendev.org/c/openstack/governance/+/962121 - pti: Remove reference to 'python setup.py' | https://review.opendev.org/c/openstack/governance/+/962920 - pti: Update to reference pyproject.toml | https://review.opendev.org/c/openstack/governance/+/962921 ==== Open For Review ==== - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Mark Vitrage project-team inactive | https://review.opendev.org/c/openstack/governance/+/963227 - Mark Venus project-team inactive | https://review.opendev.org/c/openstack/governance/+/963228 === Upcoming Events === - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ - 2025-10-04: OpenInfra Board meeting: https://board.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] 2025.2 "Flamingo" release page: https://www.openstack.org/software/openstack-flamingo [3] OpenInfra Live previewing the 2025.2 "Flamingo" release: https://www.youtube.com/watch?v=cdqL6umlM1w [4] OpenStack TC etherpad for 2026.1 "Gazpacho" PTG: https://etherpad.opendev.org/p/oct2025-ptg-os-tc [5] Appointing PTL for OpenStack Charms: https://review.opendev.org/c/openstack/governance/+/962121 [6] TC Meeting IRC Log, Sep 30th 2025:https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-30-17.00.html [7] Skyline Maintenance discussion: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] TC Meeting Agenda, Oct 7th 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic][power] Anyone using PReP partitioning support?
by Julia Kreger 06 Oct '25

06 Oct '25

Greetings Power folks! The Ironic project is curious if anyone is using PReP partitioning support? Specifically Ironic has long had a code path to manage creation of the PReP partition for booting power hardware as part of the partition image path code, but as time has gone on we're unsure if anyone is actively using this code path on newer versions of Ironic, coupled with the general decline of partition image usage. If anyone is using Power with newer versions of Ironic, please let us know if you're using partition images with Ironic, thus using PReP partitions. Specifically we're curious because we have a discussion topic which has been raised for the upcoming PTG. Thanks! -Julia

2 2

[Nova] Need to reschedule the Nova upstream meeting ⏰
by René Ribaud 06 Oct '25

06 Oct '25

Hi everyone, We need to move the current Nova upstream meeting, as most contributors, myself included, are busy in another meeting at that time. Finding a new slot is not straightforward, since some of our meetings are recurring and the daylight saving changes add additional complexity. Over the past few weeks, I tried to narrow down the possible options, and here’s a short poll with different time slots to choose from: https://framadate.org/ao12zK6wR3K3nfbF If none of these options work for you, or if you have other suggestions, please reply to this thread. Please note that we might need to adjust the schedule again later in the year, either due to daylight saving changes or if our other recurring meetings start to overlap again. Thanks for your understanding and input! Cheers, René

1 0

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

06 Oct '25

Hello Stackers, The day after tomorrow (that's 8 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 Unfortunately I'm unable to join myself this episode, but obviously feel free to discuss relevant topics. See you next time, or next week in Paris. 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

[neutron] Bug deputy report for week 40 of 2025 (September 29)
by Lajos Katona 06 Oct '25

06 Oct '25

Hi Neutrinos! Last week (week 40, from September 29) I was the Neutron bug deputy, please check the report for that week. As usual the team will discuss these bugs quickly during the weekly team meeting: https://meetings.opendev.org/#Neutron_Team_Meeting High Bugs ---------------- * Unassigned: https://bugs.launchpad.net/neutron/+bug/2126032 ([CI] Random failure network create with Error while executing command: HttpException: 503, Unable to create the network. No tenant network is available for allocation.) Only on 2025.1 branch * eventlet: https://bugs.launchpad.net/neutron/+bug/2126790 (q-dhcp process is not gracefully shutting down ) * eventlet: https://bugs.launchpad.net/neutron/+bug/2126791 (q-agt process is not gracefully shutting down ) * https://bugs.launchpad.net/neutron/+bug/2126033 (2025.2 centos jobs fails as https://trunk.rdoproject.org/centos9-2025.2/delorean-deps.repo not exists ) Yatin follows it. * https://bugs.launchpad.net/neutron/+bug/2126061 ([ovs-agent] slow start with large number of ports ) patch: https://review.opendev.org/c/openstack/neutron/+/962627 * https://bugs.launchpad.net/neutron/+bug/2126576 ([S-RBAC] Policies for local_ip_association don't work as expected), patch: https://review.opendev.org/c/openstack/neutron/+/962751 * https://bugs.launchpad.net/neutron/+bug/2126759 ([S-RBAC] Policies for l3_conntrack_helpers don't work as expected ) patch: https://review.opendev.org/c/openstack/neutron/+/962919 Medium Bugs ------------------ * Unassigned; https://bugs.launchpad.net/neutron/+bug/2126637 ([OVN] Router "after_update" event contains wrong information with GW multihoming API ) * Unassigned: https://bugs.launchpad.net/neutron/+bug/2126685 (test_add_external_port_avoid_flapping functional test failure ) * https://bugs.launchpad.net/neutron/+bug/2126570 (DHCP agent - created port not stored in cache, may cause "stale" ) patch: https://review.opendev.org/c/openstack/neutron/+/962323 * https://bugs.launchpad.net/neutron/+bug/2126588 ([OVN] The Logical_Router pinning breaks the external ports HA_Chassis_Groups ) patch: https://review.opendev.org/c/openstack/neutron/+/962746 Best wishes, Lajos Katona (lajoskatona)

1 0

[OpenStack Ansible] [Deployment] Retrieve upper constraints issue
by holywine＠outlook.com 05 Oct '25

05 Oct '25

Hello, Following the instruction here (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) step by step to deploy openstack with openstack-ansible stable/2025.1 release on four computers (Infra1, Infra2, compute1, compute2) with a fifth computer as deployer (localhost)。 During the execution of command “openstack-ansible setup-infrastructure.yml” error pops up and installation broke. The log is as the following: ... TASK [repo_server : Ensure deploy host u-c directory exists] ******************************************************************************************* ok: [infra1-repo-container-769e886d -> localhost] TASK [repo_server : Retrieve upper constraints using https] ******************************************************************************************** FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (5 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (4 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (3 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (2 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (1 retries left). fatal: [infra1-repo-container-769e886d -> localhost]: FAILED! => attempts: 5 changed: false dest: /etc/openstack_deploy/upper-constraints/upper_constraints_bfd91c04caf498be2bfda0732a2a0f9fa9306e07.txt elapsed: 0 gid: 0 group: root mode: '0644' msg: 'Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)>' owner: root size: 13007 state: file uid: 0 url: https://releases.openstack.org/constraints/upper/bfd91c04caf498be2bfda0732a… Can anybody please give a clue on what is going on and how to do troubleshooting? Thanks a lot in advance! Regards, Hewi

2 4

[OpenStack Ansible] [Deployment] Retrieve upper constraints issue
by holywine＠outlook.com 04 Oct '25

04 Oct '25

Hello, Following the instruction here (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) step by step to deploy openstack with openstack-ansible stable/2025.1 release on four computers (Infra1, Infra2, compute1, compute2) with a fifth computer as deployer (localhost)。 During the execution of command “openstack-ansible setup-infrastructure.yml” error pops up and installation broke. The log is as the following: ... TASK [repo_server : Ensure deploy host u-c directory exists] ******************************************************************************************* ok: [infra1-repo-container-769e886d -> localhost] TASK [repo_server : Retrieve upper constraints using https] ******************************************************************************************** FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (5 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (4 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (3 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (2 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (1 retries left). fatal: [infra1-repo-container-769e886d -> localhost]: FAILED! => attempts: 5 changed: false dest: /etc/openstack_deploy/upper-constraints/upper_constraints_bfd91c04caf498be2bfda0732a2a0f9fa9306e07.txt elapsed: 0 gid: 0 group: root mode: '0644' msg: 'Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)>' owner: root size: 13007 state: file uid: 0 url: https://releases.openstack.org/constraints/upper/bfd91c04caf498be2bfda0732a… Can anybody please give a clue on what is going on and how to do troubleshooting? Thanks a lot in advance! Regards, Hewi

1 0

[kolla][kolla-ansible] Managing Object Storage Backend via Kolla-Ansible
by sarah.kh09＠gmail.com 04 Oct '25

04 Oct '25

Hello everyone, We are currently using Kolla-Ansible stable/2024.1 to manage our OpenStack deployment, including both core services and the Swift object storage backend. Our goal is to manage all OpenStack services, including object storage, through a unified lifecycle management tool. We understand that managing large volumes of data can affect the performance of other services. To address this, we've separated the data flow entry points that could become bottlenecks into dedicated host groups: a load balancer and a Swift proxy. Specifically, we've created two separate host groups: one for the secondary load balancer (which serves as the initial entry point) and another for the Swift proxy services. 🔹 Key Point 1: Decoupling Swift Traffic We’ve separated the Swift proxy nodes from the other OpenStack API services. This also means that the load balancer handling Swift traffic must be distinct from the main load balancer used for services like Nova, Glance, and Neutron. 🔹 Key Point 2: Keystone Endpoint Behavior Swift still registers with the existing Keystone service. Depending on the configuration: - If the second_loadbalancer is enabled, Keystone publishes the VIP (Virtual IP) of the secondary HAProxy as the Swift endpoint. - If it’s disabled, Keystone uses the direct API address of the Swift proxy node. 🔹 Key Point 3: Two Supported Configurations Kolla-Ansible supports two architecture models for Swift: Normal and Advanced. - Normal Configuration This is the default setup in stable/2024.1, where all OpenStack services, including Swift, share the same load balancer and traffic path. - Advanced Configuration This is recommended for large-scale deployments with heavy data volumes. In this setup, Swift traffic goes through a dedicated load balancer and proxy nodes, which reduces contention and improves performance. We’d love to share this approach with the community and welcome any feedback or suggestions. Our goal is to make managing both compute and storage services within a single deployment framework as simple as possible. Thanks in advance for your insights!

1 0

[Kolla][Kolla-Ansible] Making the use of mirrors easier on container build
by Michael Still 04 Oct '25

04 Oct '25

Oh hello, For the last couple of years I've been working on trying to improve the VDI experience in OpenStack by enriching our SPICE capabilities. A series of patches has now landed in Nova that enable SPICE native console sessions from outside the cloud, I have a working (but probably not completely finished) SPICE native proxy, and the next step is adding deployment support to Kolla-Ansible so that I can start demoing an end to end implementation. I have a draft of those changes, but don't feel quite ready to push them to Gerrit just yet. As part of that I've been building my own Kolla images in my homelab CI environment for a couple of years now. I don't know about others, but for me by far the most common reason for these builds to fail is because of intermittent connectivity to upstream package repositories -- either flaky networking, random noise, or rate limiting. Increasingly I find myself carrying private patches to use local mirrors instead of the upstream sources. It occurs to me I might not be the only one with this sort of use case. I therefore wonder how the Kolla team would feel about abstracting the upstream sources of various build dependencies so that they were defined centrally? That would make it much easier both to override sources with local mirrors, as well as define exactly what upstream sources are required to conduct a build. If that's a reasonable thing to do, where would people see that list sitting? My initial thought is in the defaults for the kolla-build ansible role, but I am definitely not a Kolla expert so I am open to guidance here. Cheers, Michael -- Person on the internet. https://madebymikal.com. He / his / him.

2 2

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

02 Oct '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 11

[blazar] Meeting cancelled 16th October 2025
by Matt Crees 02 Oct '25

02 Oct '25

Hi all, Due to lack of availability of the core team, the fortnightly Blazar meeting will be cancelled on the 16th October. This means the next time that we'll meet will be at the PTG. I look forward to seeing you all there. Kind regards, Matt Crees, on behalf of the Blazar project.

1 0

OpenStack 2025.2 'Flamingo' on OpenInfra Live
by Allison Price 02 Oct '25

02 Oct '25

Hi everyone, Come learn about the latest OpenStack release, 2025.2 ‘Flamingo’ on OpenInfra Live tomorrow! We have a great lineup of community leaders who can talk about community-wide and project-specific progress. The episode will air tomorrow, October 2 at 1400 UTC and you can ask questions live that our contributors will answer during the episode. Goutham Pacha Ravi, OpenStack Technical Committee Iury Gregory, Ironic Rene Ribaud, Nova Carlos Silva, Manila Brian Haley, Neutron You can watch on YouTube[1] or LinkedIn[2]. See you there! Cheers, Allison [1] https://www.youtube.com/watch?v=cdqL6umlM1w [2] https://www.linkedin.com/posts/openinfra-foundation_learn-more-about-the-32…

1 1

Ironic Community dinner/meet-up at Open Infra Summit Europe 2025
by Riccardo Pittau 02 Oct '25

02 Oct '25

Hello ironicers! The Ironic community is organizing a dinner/meet-up on October Friday 17th in Paris, the first night of the Open Infra Summit Europe. If you'd like to join please add your name here: https://etherpad.opendev.org/p/Ironic_OIS_community_dinner_in_Paris We'll collect the number of participants by next Monday October 6th to be able to book enough time in advance. Ciao Riccardo

1 0

Short Bitergia dashboard outage due to maintenance
by Ildiko Vancsa 01 Oct '25

01 Oct '25

Hi OpenStack community, I’m reaching out to let you know that the OpenStack Bitergia metrics dashboard[1] will be unavailable for a short period of time due to scheduled maintenance, where the underlying OpenSearch cluster will be updated. Details of the downtime: * Start Date: Monday, October 06 at 800 UTC * End Date: Tuesday, October 07 at 1600 UTC __During this maintenance window, the dashboard will be inaccessible.__ Please also note that data updates will not resume until Wednesday (October 08). Thank you for your understanding. Best Regards, Ildikó [1] https://openstack.biterg.io/app/dashboards#/view/Overview

1 0

OpenStack 2025.2 "Flamingo" is officially released!
by Elõd Illés 01 Oct '25

01 Oct '25

Hello OpenStack community, The official OpenStack 2025.2 Flamingo release announcement has been sent out: https://lists.openstack.org/archives/list/openstack-announce@lists.openstac… Thanks to all who were a part of the 2025.2 Flamingo development cycle! This marks the official opening of the openstack/releases repository for 2026.1 Gazpacho releases, and freezes are now lifted. stable/2025.2 is now a fully normal stable branch, and the normal stable policy applies from now on. Thanks, Előd Illés on behalf of the Release Management team

3 2

[ptl][tc] OpenStack 2025.2 Flamingo OpenInfra Live
by Allison Price 01 Oct '25

01 Oct '25

Hi everyone, As we get closer to next week’s release, I wanted to reach out about doing an OpenInfra Live episode about OpenStack 2025.2 ‘Flamingo.” If you are a PTL or TC member who would like to present project highlights, please let me know. The episode will air next Thursday, October 2 at 1400 UTC. If you are unfamiliar, you can check out the Epoxy version here: https://www.youtube.com/watch?v=qX2-8oyFVPk Cheers, Allison

5 7

East-West and the compute VM flows come to a centralized gateway for security audit
by Andy Zhou 01 Oct '25

01 Oct '25

Hello Everyone, Any advice about configure of Openstack or OVN/OVS, to implement a centralized gateway of all the flows of VMs for flow audit? Since the default type is distributed mode for the East-West flow, I want to know if we can change to a centralized one? Thank you! Best regards, Andy Zhou

2 2

I can not get user list with project in openstack version epoxy
by cheung 01 Oct '25

01 Oct '25

Dears: I can get user list with project in openstack version caracal. # openstack project list -f value 7fb2be327b4c4f9e83db04a4b5cb922b service c1bcb532eca44aadabb028b1ee715412 admin de4012f880e7408f9fb21b67930c21ac project_it # openstack user list -f value 84b39214b13148d68bf88242aa6abdf9 admin 62f7113645c24199a9946cd16911ca64 glance b21da7173fe3400f91d3eb73f392474d nova 95a6ff7b9bba42f9aadf3b07a0811330 placement 4ac268a8e75b4a4288f067e28ad14425 neutron 46fa578d54624e06ae2e0b3761a67de7 cinder 1c1646579b5042a6bb463e8f46b7762f test001 57689f8310e744889dce33d6b32f4524 test002 # openstack user list -f value --project project_it 1c1646579b5042a6bb463e8f46b7762f test001 57689f8310e744889dce33d6b32f4524 test002 # openstack user list -f value --project service 4ac268a8e75b4a4288f067e28ad14425 neutron 46fa578d54624e06ae2e0b3761a67de7 cinder b21da7173fe3400f91d3eb73f392474d nova 62f7113645c24199a9946cd16911ca64 glance 95a6ff7b9bba42f9aadf3b07a0811330 placement # dpkg -l| grep keyston ii keystone 2:25.0.0-0ubuntu1 all OpenStack identity service - Daemons ii keystone-common 2:25.0.0-0ubuntu1 all OpenStack identity service - Common files ii python3-keystone 2:25.0.0-0ubuntu1 all OpenStack identity service - Python 3 library ii python3-keystoneauth1 5.6.0-0ubuntu1.1 all authentication library for OpenStack Identity - Python 3.x ii python3-keystoneclient 1:5.4.0-0ubuntu1 all client library for the OpenStack Keystone API - Python 3.x ii python3-keystonemiddleware 10.6.0-0ubuntu1 all Middleware for OpenStack Identity (Keystone) - Python 3.x But I can not get user list in epoxy version. # openstack project list -f value 0087125cb3564da39a5e87dc61aece78 project_it 8b6a848d2d7841118567f1dad2eeb9f5 admin dcaa69462fd3447ca75133a8ce4b95c3 service # openstack user list -f value 27bd419eb7bc4da58f9e246232a12720 placement 7c5a457f461440e5a24a368f827ecafc admin 846cca4cb4394d1ab4e8d95dffb63ce2 glance 92122f012abb4db38a0d3ca287c04122 nova ad039b4d1f4f4c42a59e69e56eef4f16 neutron ebde13fec7584f5180becb88afa0e1c7 cinder f4cf0b16f52e407d994e2aa729936580 test002 f9ee38a0a4cb412dbd293a83b5b32dc5 test001 # openstack user list -f value --project project_it Either group or user should be specified # openstack user list -f value --project service Either group or user should be specified What do I miss? I need to read which one document? 本電子郵件及其所有附件所含之資訊均屬機密，僅供指定之收件人使用，未經寄件人同意不得揭露、複製或散布本電子郵件。若您並非指定之收件人，請勿使用、保存或揭露本電子郵件之任何部分，並請立即通知寄件人並完全刪除本電子郵件。網路通訊可能含有病毒，收件人應自行確認本郵件是否安全，若因此造成損害，寄件人恕不負責。 The information contained in this communication and attachment is confidential and is intended only for the use of the recipient to which this communication is addressed. Any disclosure, copying or distribution of this communication without the sender's consents is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this communication entirely without using, retaining, or disclosing any of its contents. Internet communications cannot be guaranteed to be virus-free. The recipient is responsible for ensuring that this communication is virus free and the sender accepts no liability for any damages caused by virus transmitted by this communication.

3 4

[openstack-ansible] watcher support with openstack-ansible
by keshav bareja 01 Oct '25

01 Oct '25

Hi Team We would like to know if there is any plan to add watcher service support in openstack-ansible. Our current release is below and we need to add watcher service for our release. Openstack-ansible Caracal 2024.1 Regards Keshav

2 2