- openstack-discuss - lists.openstack.org

[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 20 Oct '25

20 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 18 Oct '25

18 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