- openstack-discuss - lists.openstack.org

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

09 Dec '25

Hello Stackers, We're sixteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Project teams are reviewing design specifications and observing spec freezes to advance designs to the implementation phase. In the past week, the OpenStack Technical Committee didn't merge any new governance updates; however, a few change proposals are undergoing community review. We're looking for volunteers to shadow the election officials as they set up and run the TC and PTL elections for the 2026.2 release cycle. If you're interested, please reach out to me, or drop by the #openstack-election IRC channel on OFTC. === Weekly Meeting === The last meeting of the OpenStack Technical Committee occurred on December 2nd, 2025, in the #openstack-tc IRC channel on OFTC [2]. The TC reviewed several outstanding tasks, one of which was the direction in which the FIPS compliance goal was proceeding. This cross-project goal [3] is being moved back to "proposed" status, seeking feedback regarding testing and a goal champion. The focus of the meeting was a deep dive into the friction surrounding significant changes within the community. The TC acknowledged a growing sentiment that existing governance processes are perceived as "bad bureaucracy," creating a situation where policies suffer from "bit rot." For example, we've long had a PTI for Golang despite a lack of actual use—because contributors feel that attempting to update these rules is futile or destined for rejection. We debated potential remedies, such as reviving the "Ideas" repository [4], but concluded that the root issue lies in some outdated guiding documents and practices. The consensus was that the challenges in making big changes stem from a misalignment between current reality and codified policy, leading to a culture where contributors assume the rules cannot be touched. Consequently, we noted that we'd like to review and rewrite the "Technical Vision" document [5]. Since vision statements are intended to be time-bounded, the current version should be considered obsolete. We hope that refreshing this high-level document will serve as the foundation to subsequently prune outdated policies and demonstrate that the community's norms are not immutable. This discussion will continue in this week's meeting that will be held today, December 9th, 2025, in the #openstack-tc channel on OFTC at 1700 UTC. Please see the agenda on the meeting's wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - Alter public cloud SIG chair | https://review.opendev.org/c/openstack/governance/+/969371 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-12-12: Athens OpenStack User Group Meetup: https://meetup.com/athens-openstack-user-group/events/312235216 - 2025-12-16: Twelve Clouds of Christmas: https://www.meetup.com/openinfra-austin/events/312269596 - 2026-01-08: 2026.1 Milestone 2 - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] TC Meeting IRC Log, Dec 2 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-02-17.00.html [3] FIPS Compliance Goal: https://governance.openstack.org/tc/goals/selected/fips.html [4] Ideas for OpenStack: https://governance.openstack.org/ideas/ [5] Vision for OpenStack Clouds: https://governance.openstack.org/tc/reference/technical-vision.html [6] TC Meeting Agenda, Dec 9 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[octavia] compute id for a Octavia pool member
by Max Harmathy 08 Dec '25

08 Dec '25

Hello OpenStack community, I regularly face the following problem: From time to time I get notified about issues with some load-balancers where often the issue lies in connectivity between the health monitor and some of the pool members. Now for investigating the problem I often need to know the ID of the server (compute id) for a certain pool member. I haven't found a straightforward way, since the information the OpenStack client provides for a given pool member (openstack loadbalancer member show ...) doesn't include the compute id. I usually try to find out the IP address of the pool member and then match that against the list of servers. But that process is quite tedious. Is there a better way to do this natively or has someone made a tool for that job? Regards, Max -- Max Harmathy UhuruTec AG Tel +49 151 16 341 719 max.harmathy(a)uhurutec.com https://www.uhurutec.com Industriestraße 4 D-70565 Stuttgart Vorsitzender des Aufsichtsrats: Maximilian Buchberger Vorstand: Matthias Haag, Jan Klippel Registergericht Stuttgart, HRB 785603 USt-IdNr: DE354021144

3 3

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

08 Dec '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 14

[all][oslo][cinder][glance][nova][sdk][trove] Upcoming migration of whereto to PCRE2
by Takashi Kajinami 08 Dec '25

08 Dec '25

Hi ! I'm sending this email so that you'd be aware of an upcoming breaking change in the whereto library, because you might need to update your projects (especially their bindep.txt files) to adopt your projects to the change. The whereto library is a tiny library to generate redirect rules in Apache and has been used in documentation build in several projects. This library has been dependent on python-pcre, which requires the following packages. - libpcre3-dev in Debian-based operating systems (such as Debian or Ubuntu) - pcre-devel in RHEL-based operating systems (such as RHEL or CentOS Stream) However these packages are no longer provided by newer operating systems and we have to replace these by PCRE 2. - Debian removed libpcre3-dev because PCRE 3 is obsolete and it is recommended to replace it by PCRE 2 [1]. - RHEL 10 removed PCRE and PCRE 2 is a recommended replacement. I've already proposed the change[1] of whereto to replace python-pcre by pcre2 (which requires pcre2 packages from OS). I'll create a new release of whereto shortly after this change is merged. Once the new release hits the upper constraints, libpcre3-dev and pcre-devel in bindep.txt in each repository should be replaced. See [3] to learn how the change should look like. So far I'm planning to take care of this transition, but it'd be nice if I can ask for some attention about it. Please let me know if you have any question. Thank you, Takashi [1] https://lists.debian.org/debian-devel/2021/11/msg00176.html [2] https://review.opendev.org/c/openstack/whereto/+/970061 [3] https://review.opendev.org/c/openstack/whereto/+/970061/4/bindep.txt -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[Nova] Reminder no upstream meeting this week.
by René Ribaud 08 Dec '25

08 Dec '25

Hello, Just a quick note to remind everyone that there is no meeting scheduled for today. We will resume as usual next week. Best regards, René

1 0

[neutron] Bug deputy report - week of Dec 1st
by Slawek Kaplonski 08 Dec '25

08 Dec '25

Hi, I was bug deputy last week. It was very quiet week with just couple of new bugs opened. Below is summary of those: ### Critical - https://bugs.launchpad.net/neutron/+bug/2133807 - tap-as-a-service py313 jobs timeout - CI issue with py313 job, assigned to Lajos, fix proposed https://review.opendev.org/c/openstack/tap-as-a-service/+/969567 ### High - https://bugs.launchpad.net/neutron/+bug/2133487 - ovs_agent main thread raises ValueError on calling os_ken parser without kwargs - **not assigned**, it was also raised on IRC channel, - https://bugs.launchpad.net/neutron/+bug/2134338 - [OVN] Maintenance LRP prefix adding fails over 'dict' doesn't have 'name' attribute - fix already proposed https://review.opendev.org/c/openstack/neutron/+/970056 ### Medium None ### Low - https://bugs.launchpad.net/neutron/+bug/2133796 - [OVN] The OVN agent config option "[agent]extensions" is not present in the default config file - assigned to Rodolfo, ### RFE - https://bugs.launchpad.net/neutron/+bug/2134096 - [OVN] Add both direction to tap mirror - this seems to be very small RFE but technically speaking it is not a bug but request for new feature, I'm don't think we need to discuss that during the drivers meeting really, please take a look at it and comment there - if we will see that discussion is needed, we can always add it to the drivers meeting agenda later, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[release] Release countdown for week R-16, Dec 08 - Dec 12
by Elõd Illés 05 Dec '25

05 Dec '25

Development Focus ----------------- The Gazpacho-2 milestone will happen next month, on January 8th, 2026. 2026.1 Gazpacho-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/gazpacho/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/gazpa… You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/gazpacho/schedule.html#g-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Gazpacho-2 Milestone: January 8th, 2026 Előd Illés irc: elodilles @ #openstack-release

1 0

Re: using postgresql in production
by Artem Goncharov 05 Dec '25

05 Dec '25

> > On Fri, 5 Dec 2025, 03:25 Sa Pham, <saphi070(a)gmail.com> wrote: > >> HI Artem, >> >> Could you share why you run Keystone with Postgresql ? >> >> I'm running Keystone with Postgresql as well, because my other >> application is using Postgresql so I don't want to deploy two Database >> servers. >> And it's working well without issue. >> > It is more or less a personal preference after working professionally for >> decades with both databases. Postgres features remind me more other major >> relational databases, while MySQL goes "own way". It's not about certain >> needs of Keystone, this is just a personal preference. >> > > > >> >> >> On Thu, Dec 4, 2025 at 11:10 PM Artem Goncharov < >> artem.goncharov(a)gmail.com> wrote: >> >>> In my local tests I always use postgres for Keystone (as well in the >>> keystone-ng testing) and it works. But I agree we do not have dedicated >>> tests as of now, so some edge cases may be broken >>> >>> On Thu, 4 Dec 2025 at 16:37, Sean Mooney <smooney(a)redhat.com> wrote: >>> >>>> nova does not have tempet/devstack jobs either >>>> however we never officially deprecated or removed support for PostgreSQL >>>> >>>> we still test it in our unit tests to ensure the schema applies and some >>>> other minor test coverage but its also been a few years since there was >>>> any real >>>> end to end testing. >>>> >>>> >>>> >>>> On 04/12/2025 14:36, Julia Kreger wrote: >>>> > Greetings, >>>> > >>>> > Ironic ended up removing CI jobs for postgres back in 2024[0] when >>>> > keystone merged postgres incompatible changes which broke the CI job >>>> > and rendered it impossible to test. Previous to that, I think in 2023 >>>> > or 2022, neutron made some changes but quickly fixed the breaking >>>> > changes once they were highlighted. The linked change has some back >>>> > and forth and the mailing list post[1] which spawned job removal from >>>> > Ironic. Ultimately, while people have expressed interest, that has >>>> > never really materialized into action or engagement to keep postgres >>>> > support in a known working state. Unfortunately slight schema and >>>> > behavior differences between the two database platforms really forces >>>> > the need to perform that level of testing as well, which means one is >>>> > likely to encounter issues if they just try to create and use a >>>> > service's database in postgres at this point. >>>> > >>>> > Hope this has helped. >>>> > >>>> > -Julia >>>> > >>>> > [0]: https://review.opendev.org/c/openstack/ironic/+/931055 >>>> > [1]: >>>> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>>> > >>>> > On Thu, Dec 4, 2025 at 3:32 AM Slawek Kaplonski <skaplons(a)redhat.com> >>>> wrote: >>>> >> Hi, >>>> >> >>>> >> Dnia czwartek, 4 grudnia 2025 11:15:55 czas środkowoeuropejski >>>> standardowy Maksim Malchuk pisze: >>>> >>> Hi Slawek, >>>> >>> >>>> >>> I remember some presentations from the summit years ago but can't >>>> find >>>> >>> them. Do you have any links about this information? Maybe docs or >>>> gerrit >>>> >>> commits? >>>> >> I only got >>>> https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.… >>>> and I remember we have discussed that few cycles back in the Neutron room >>>> during the PTG. I don't remember exactly which PTG it was however >>>> >> >>>> >>> >>>> >>> On Thu, Dec 4, 2025 at 11:49 AM Slawek Kaplonski < >>>> skaplons(a)redhat.com> >>>> >>> wrote: >>>> >>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> Dnia czwartek, 4 grudnia 2025 08:26:17 czas środkowoeuropejski >>>> standardowy >>>> >>>> Jiatong Shen pisze: >>>> >>>>> Hello community, >>>> >>>>> >>>> >>>>> We are analyzing the possibility of using PostgreSQL in >>>> production. The >>>> >>>>> reason behind is that the PostgreSQL community is very open and >>>> growing >>>> >>>>> fast, besides many Chinese companies provide PG compatibility. >>>> >>>>> >>>> >>>>> My question is what are the pros and cons between using PG and >>>> MariaDB. >>>> >>>> Are >>>> >>>>> there any tools available to do online data migration for legacy >>>> >>>>> environments? Any insight is deeply appreciated. Thank you. >>>> >>>>> -- >>>> >>>>> >>>> >>>>> Best Regards, >>>> >>>>> >>>> >>>>> Jiatong Shen >>>> >>>>> >>>> >>>> It may be hard as some time ago at least some projects like e.g. >>>> Neutron >>>> >>>> stopped testing and supporting Postrgesql officially. So you may >>>> expect >>>> >>>> some issues there I believe. >>>> >>>> >>>> >>>> -- >>>> >>>> Slawek Kaplonski >>>> >>>> Principal Software Engineer >>>> >>>> Red Hat >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Regards, >>>> >>> Maksim Malchuk >>>> >>> >>>> >> >>>> >> -- >>>> >> Slawek Kaplonski >>>> >> Principal Software Engineer >>>> >> Red Hat >>>> >>>> >> >> -- >> Sa Pham Dang >> Skype: great_bn >> Phone/Telegram: 0986.849.582 >> >> >> ---- typed from mobile, auto-correct typos assumed ----

1 0

Fwd: using postgresql in production
by Artem Goncharov 05 Dec '25

05 Dec '25

On Fri, 5 Dec 2025, 03:25 Sa Pham, <saphi070(a)gmail.com> wrote: > HI Artem, > > Could you share why you run Keystone with Postgresql ? > > I'm running Keystone with Postgresql as well, because my other application > is using Postgresql so I don't want to deploy two Database servers. > And it's working well without issue. > It is more or less a personal preference after working professionally for decades with both databases. Postgres features remind me more other major relational databases, while MySQL goes "own way". It's not about certain needs of Keystone, this is just a personal preference. > > > On Thu, Dec 4, 2025 at 11:10 PM Artem Goncharov <artem.goncharov(a)gmail.com> > wrote: > >> In my local tests I always use postgres for Keystone (as well in the >> keystone-ng testing) and it works. But I agree we do not have dedicated >> tests as of now, so some edge cases may be broken >> >> On Thu, 4 Dec 2025 at 16:37, Sean Mooney <smooney(a)redhat.com> wrote: >> >>> nova does not have tempet/devstack jobs either >>> however we never officially deprecated or removed support for PostgreSQL >>> >>> we still test it in our unit tests to ensure the schema applies and some >>> other minor test coverage but its also been a few years since there was >>> any real >>> end to end testing. >>> >>> >>> >>> On 04/12/2025 14:36, Julia Kreger wrote: >>> > Greetings, >>> > >>> > Ironic ended up removing CI jobs for postgres back in 2024[0] when >>> > keystone merged postgres incompatible changes which broke the CI job >>> > and rendered it impossible to test. Previous to that, I think in 2023 >>> > or 2022, neutron made some changes but quickly fixed the breaking >>> > changes once they were highlighted. The linked change has some back >>> > and forth and the mailing list post[1] which spawned job removal from >>> > Ironic. Ultimately, while people have expressed interest, that has >>> > never really materialized into action or engagement to keep postgres >>> > support in a known working state. Unfortunately slight schema and >>> > behavior differences between the two database platforms really forces >>> > the need to perform that level of testing as well, which means one is >>> > likely to encounter issues if they just try to create and use a >>> > service's database in postgres at this point. >>> > >>> > Hope this has helped. >>> > >>> > -Julia >>> > >>> > [0]: https://review.opendev.org/c/openstack/ironic/+/931055 >>> > [1]: >>> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>> > >>> > On Thu, Dec 4, 2025 at 3:32 AM Slawek Kaplonski <skaplons(a)redhat.com> >>> wrote: >>> >> Hi, >>> >> >>> >> Dnia czwartek, 4 grudnia 2025 11:15:55 czas środkowoeuropejski >>> standardowy Maksim Malchuk pisze: >>> >>> Hi Slawek, >>> >>> >>> >>> I remember some presentations from the summit years ago but can't >>> find >>> >>> them. Do you have any links about this information? Maybe docs or >>> gerrit >>> >>> commits? >>> >> I only got >>> https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.… >>> and I remember we have discussed that few cycles back in the Neutron room >>> during the PTG. I don't remember exactly which PTG it was however >>> >> >>> >>> >>> >>> On Thu, Dec 4, 2025 at 11:49 AM Slawek Kaplonski < >>> skaplons(a)redhat.com> >>> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> Dnia czwartek, 4 grudnia 2025 08:26:17 czas środkowoeuropejski >>> standardowy >>> >>>> Jiatong Shen pisze: >>> >>>>> Hello community, >>> >>>>> >>> >>>>> We are analyzing the possibility of using PostgreSQL in >>> production. The >>> >>>>> reason behind is that the PostgreSQL community is very open and >>> growing >>> >>>>> fast, besides many Chinese companies provide PG compatibility. >>> >>>>> >>> >>>>> My question is what are the pros and cons between using PG and >>> MariaDB. >>> >>>> Are >>> >>>>> there any tools available to do online data migration for legacy >>> >>>>> environments? Any insight is deeply appreciated. Thank you. >>> >>>>> -- >>> >>>>> >>> >>>>> Best Regards, >>> >>>>> >>> >>>>> Jiatong Shen >>> >>>>> >>> >>>> It may be hard as some time ago at least some projects like e.g. >>> Neutron >>> >>>> stopped testing and supporting Postrgesql officially. So you may >>> expect >>> >>>> some issues there I believe. >>> >>>> >>> >>>> -- >>> >>>> Slawek Kaplonski >>> >>>> Principal Software Engineer >>> >>>> Red Hat >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Maksim Malchuk >>> >>> >>> >> >>> >> -- >>> >> Slawek Kaplonski >>> >> Principal Software Engineer >>> >> Red Hat >>> >>> > > -- > Sa Pham Dang > Skype: great_bn > Phone/Telegram: 0986.849.582 > > >

1 0

using postgresql in production
by Jiatong Shen 05 Dec '25

05 Dec '25

Hello community, We are analyzing the possibility of using PostgreSQL in production. The reason behind is that the PostgreSQL community is very open and growing fast, besides many Chinese companies provide PG compatibility. My question is what are the pros and cons between using PG and MariaDB. Are there any tools available to do online data migration for legacy environments? Any insight is deeply appreciated. Thank you. -- Best Regards, Jiatong Shen

7 7