January 2026 - openstack-discuss - lists.openstack.org

[nova] Ephemeral storage potential features
by Karol Klimaszewski 26 Jan '26

26 Jan '26

Hello, In my company (CloudFerro) we have developed two features related to nova ephemeral storage (with libvirt virt driver) - "SPDK-based ephemeral storage backend" and "Multiple ephemeral storage backend handling" (both described below). Would these features be appropriate to be added to upstream? If yes, then should I start with creating a blueprint and proposing a spec for each of them so it is more clear what we want to introduce? Of course not both at once, since there is some code that makes one work with the other. For us it would probably be best if we upstreamed "SPDK-based ephemeral storage backend" first and then upstreamed "Multiple ephemeral storage backend handling" Description of SPDK-based ephemeral storage backend: We add a new possible value for [libvirt]/images_type in nova.conf: spdk_lvol. If this value is set then local disks of instances are handled as logical volumes (lvols). of locally run SPDK instance (on the same compute as VM). See https://spdk.io/doc/logical_volumes.html#lvol for docs on this subject. These are essentially a part of local NVMe disk managed by SPDK. We create and manage those lvols by making calls from nova-compute to SPDK instance with RPC (https://spdk.io/doc/jsonrpc.html) using provided python library (https://github.com/spdk/spdk/blob/master/python/README.md) We attach those lvols to instances by exposing them as vhost-blk devices (see https://spdk.io/doc/vhost.html) and specifying them as disks with source_type='vhostuser'. This method of exposing NVMe local storage allows for much better I/O performance than exposing them from local filesystem. We currently have working: creating, deleting, cold-migrating, shelving, snapshots, unshelving VMs with this storage backend. We don't have live migration working yet but have it in plans. This feature includes changes only to nova. Description of Multiple ephemeral storage backend handling: We add a new configuration option [libvirt]/supported_image_types to nova.conf of nova-compute and change the meaning of [libvirt]/images_type to mean default image type. If libvirt:image_type extra_spec is specified in flavor then VM is scheduled on compute with appropriate image type in its [libvirt]/supported_image_types. We use potentially multiple DISK_GB resource providers and construct appropriate request groups to handle this scheduling. This spec is also used to fill driver_info.libvirt.image_type field of BDMs with destination_type=local of this VM. (driver_info is new JSON serialized field of BDM) Then in compute if BDM specifies this field we use its value instead of [libvirt]/images_type to decide on imagebackend to use for it. This method of handling multiple backends only works after being enabled by administrators by setting libvirt:image_type on all their flavors and running nova-manage commands that update existing VMs. Without enabling everything works as it was before. This feature includes changes to nova and some new traits in os-traits (One per possible value of [libvirt]/images_type + one extra) Best regards, Karol Klimaszewski

2 7

How to access OpenStack instances from the bastion node when deploying OpenStack using Kolla-Ansible
by ussefelboukhari＠gmail.com 25 Jan '26

25 Jan '26

In test environments, some users choose to build their infrastructure inside KVM virtual machines, while others use cloud instances such as EC2 bare-metal that support nested virtualization. After deploying OpenStack, many of them face a major issue: they are unable to access their OpenStack instances. I encountered the same problem myself. After several weeks of intensive troubleshooting, I eventually found a solution. That is why I would like to share this solution with others who face the same issue, and hopefully contribute to the OpenStack community by providing recommendations that could be added to the official OpenStack documentation.

1 0

[horizon] Cancelling weekly meeting on Jan 28
by Tatiana Ovchinnikova 23 Jan '26

23 Jan '26

Hello team, I will not be around for our meeting on January 28, so as we discussed earlier I am cancelling it. See you all on February 4. With kind regards, Tatiana

1 0

[Kolla] ovn failed to install because of notifying handlers
by Michal Arbet 23 Jan '26

23 Jan '26

Hi, Ovn is failing currently, https://aa9bea214d792ca72a31-ab9965a682a78200f296c9df29ce08ed.ssl.cf2.rackc… Caused by https://review.opendev.org/c/openstack/kolla-ansible/+/940428 I probably have a fix ..root cause is that item of course don't have a key ... Kevko Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on January 23, 2026
by Ildiko Vancsa 23 Jan '26

23 Jan '26

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the first OpenStack Ops Radio Hour[1] in 2026 is scheduled to happen on __January 23rd, 2026 at 1300UTC,__ which is next Friday! 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. Topics for this call: - Plans for 2026 - Ops Radio Hour Survey draft: https://etherpad.opendev.org/p/openstack_ops_radiohour_survey 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> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + 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 January 23rd! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 2

[Neutron] VPNaaS one to many subnets
by Robert N 23 Jan '26

23 Jan '26

Dear Community, I'm trying to configure VPNaaS between 2 sites, both sites have one openstack subnet with 2 networks. left side. subnet 192.168.0.0/24 gw 192.168.0.1 subnet 172.0.0.0/16 - the scope for this is just local network, it doesn't have to be routed outside. this subnet is broke into /24 subnets and assigned to differnt nodes on the network, and they are reachable with explicit routes on the router. It's basically a kubernetes pod network, and the routes are managed by openstack-cloud-controller-manager. right side subnet 192.168.1.0/24 gw 192.168.1.1 subnet 172.1.0.0/16 I need connectivity between the 2 sites on both layers 192.... and 172... so I tried to endpoint groups, a local of type subnet and a peer of type cidr with the cidrs `192.168.0.0/24,172.0.0.0/16` and respectively ` 192.168.1.0/24,172.1.0.0/16`. With this setup the vpn connection doesn't come up. If I create the peer cidr with only one cidr `192.168.0.0/24` and respectively `192.168.1.0/24` the vpn connection becomes active and works as expected for the 192... netowrks. I tried adding manually the routes for the 172.0.0.0/16 on one side and 172.1.0.0/16 o the other side with to the same gateway `169.254.0.2` but it doesn't work. I'm wondering how could I configure the VPN to have both networks routed 192... and 172... Appreciating any input on the topic. Cheers, Robert

1 0

Mark your calendars! April 2026 PTG Dates & Registration
by Kendall Nelson 22 Jan '26

22 Jan '26

Hello Everyone! The dates are set for the next PTG[1]! It will take place April 20-24, 2026! Registration is now open[2] and free for all to attend. Please stay tuned! Soon I will be sending the team sign up survey to collect those teams interested in participating this April. -Kendall Nelson (diablo_rojo) [1] PTG Website: https://openinfra.org/ptg/ [2] PTG Registration: https://ptg.openinfra.org/

1 0

[kolla] Dropping support for building and deploying InfluxDB
by Michał Nasiadka 22 Jan '26

22 Jan '26

Hello Koalas, Kolla project plans to drop support for InfluxDB, given that current version supported by the project is v1, which is in End of Life state. We haven’t seen any interest in introducing v2 support and given that the core team also has no interest in doing that - we’re dropping support. See https://review.opendev.org/q/topic:%22kolla_drop_influxdb%22 Michal

1 0

Zuul failures for openstack-tox-py313
by Nimesh Desai 22 Jan '26

22 Jan '26

Hi, I am observing following error in the zuul run the given patch. There have been no changes in this patch recently, but zuul started failing for this package error. Is this also seen in other patches? Patch: [IBM SVf Driver] Define meaningful names for error constants | https://review.opendev.org/c/openstack/cinder/+/959683 Zuul target: openstack-tox-py313 Zuul error: https://zuul.opendev.org/t/openstack/build/9491515d2dbb473c922ba1e3ba13b19b No package matching 'libpcre3-dev' is available 2026-01-19 03:30:29.510623 | TASK [bindep : Install distro packages from bindep] 2026-01-19 03:30:31.956565 | debian-trixie | ERROR 2026-01-19 03:30:31.956930 | debian-trixie | { 2026-01-19 03:30:31.957003 | debian-trixie | "msg": "No package matching 'libpcre3-dev' is available" 2026-01-19 03:30:31.957062 | debian-trixie | } Regards, Nimesh Desai

4 4

[neutron] Next week CI meeting cancelled
by Yatin Karel 22 Jan '26

22 Jan '26

Hello Neutron Team !! As discussed in the last CI meeting I will not be around upcoming Monday, so cancelling the meeting. We will now have our next CI meeting on 02nd February. -- Thanks and Regards Yatin Karel

1 0

[dev][nova] Intel TDX support
by Anton Iacobaeus 21 Jan '26

21 Jan '26

Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton

3 3

[all][oslo][cinder][glance][nova][sdk][trove] Upcoming migration of whereto to PCRE2
by Takashi Kajinami 21 Jan '26

21 Jan '26

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 1

[tc][ops] Any consensus for what's next after uWSGI ?
by opensource＠rfc2549.ca 20 Jan '26

20 Jan '26

Hi, This thread from 2023 generated some discussion around uWSGI being in maintenance mode but my search doesn't yield more recent developments around $topic. uWSGI is still in maintenance mode 3 years later. Back at the Epoxy PTG, openstack-ansible had a topic [1] to figure a replacement but after checking with Dimitri, this has not happened yet and they are still relying on uWSGI at this time. I was curious if the community had opinions on what the next "standard" wsgi runtime might be from options like gunicorn, uvicorn or granian, to name a few. I realize this is not so much a problem for individual OpenStack projects but like mentioned in [0], it is much nicer if any of the options are well supported/documented from an operator perspective. Thanks ! [0]: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/03234… [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

4 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-10)
by Goutham Pacha Ravi 19 Jan '26

19 Jan '26

Hello Stackers, We're 10 weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Now that we're past milestone-2 of this release cycle, project teams are actively reviewing implementation patches for specifications. The next project-wide deadline is the feature freeze (February 26, 2026), but please consult the release calendar to see project-specific deadlines in the interim. In the past week, the OpenStack Technical Committee reprised a weekly meeting after a month and caught up on several ongoing governance concerns. The governance of the "keystoneauth" repository was moved from the Keystone project team to the OpenStackSDK project team where we think it will see better reviewer attention. Apart from that, there are several open governance proposals that are being reviewed by the community. === Weekly Meeting === The OpenStack TC met over IRC on January 13th 2026 on the #openstack-tc channel on OFTC to kick off the year by synchronizing on several high-level initiatives [2]. This includes the transition to the 2026.2 "Hibiscus" release cycle and aligning our technical efforts with the Foundation's upcoming marketing themes [3] and the "Next Level" board goals [4]. We also discussed the immediate sunsetting of Bitergia dashboards [5]. As we transition to LFX, the committee spoke about the importance of project metrics such as review participation and merge timelines. Programmatically graphing this sort of information needs context-awareness and the dashboards must not rely on inaccurate assumptions about contributors' email addresses, working hours or time zones. We reiterated a critical resource gap within the Ansible SIG. The openstack.cloud collection remains a dependency for official projects like OpenStack-Ansible and Kolla, yet it currently lacks sufficient review bandwidth; we are looking for volunteers to help sustain this deliverable. Finally, we discussed the effort to support AlmaLinux on non-v3 x86 processors to maximize hardware reuse; while we have immediate workarounds for DevStack, we are seeking a native OVN package build on this platform. The next meeting of the OpenStack TC is today, January 20th 2026 at 0800 UTC. Please note this earlier time; it accommodates our APAC colleagues. The meeting will be hosted on the #openstack-tc channel on OFTC and the agenda is available on the meeting's wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Move keystoneauth under OpenStackSDK governance | https://review.opendev.org/c/openstack/governance/+/971178 ==== Open For Review ==== - Revive os_freezer role for OSA | https://review.opendev.org/c/openstack/governance/+/973364 - Revive os_watcher role for OSA | https://review.opendev.org/c/openstack/governance/+/973385 - Remove rbd-iscsi-client from release management | https://review.opendev.org/c/openstack/governance/+/972316 - Remove barbican-ui from release management | https://review.opendev.org/c/openstack/governance/+/972315 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-01-31: FOSDEM 2026: https://www.meetup.com/brussels-openinfra-meetup-group/events/312867974 - 2026-02-26: 2026.1 "Gazpacho" Feature Freeze / Milestone 3 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, Jan 13 2026:https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-13-17.01.html [3] 2026 OpenStack Marketing and Messaging Priorities: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] Taking OpenStack to the Next Level in 2026: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenStack Dashboards: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Jan 20 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy Jan 12 - Jan 18
by Helen Chen 19 Jan '26

19 Jan '26

Hello Neutrinos: This is the list of bugs created during the last week: * High: ** Neutron-ovn-db-sync-util cleans ACL rules not really related to security groups at all (https://bugs.launchpad.net/neutron/+bug/2138430) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973648 ** [OVN] Exception when a ``Logical_Router_Port`` is deleted (https://bugs.launchpad.net/neutron/+bug/2138468) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973584 * Medium: ** [OVN] Exception during the port UP setup if the LSP has been deleted (https://bugs.launchpad.net/neutron/+bug/2138477) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973599 ** [OVN] LRP not present in ``check_redirect_type_router_gateway_ports`` (https://bugs.launchpad.net/neutron/+bug/2138484) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973602 Thanks, Helen

1 0

[openstack][share]Openstack Workload Balancer
by Nguyễn Hữu Khôi 18 Jan '26

18 Jan '26

Hello, I have a script to make Openstack workload balance(CPU and RAM). I would like to share it. This script is not perfect but I hope it will be useful for you. https://github.com/nguyenhuukhoi/OpenstackWBalancer Nguyen Huu Khoi

1 0

[CVE-2026-22797] OpenStack keystonemiddleware: Privilege Escalation via Identity Headers in External OAuth2 Tokens (CVE-2026-22797)
by Jeremy Stanley 16 Jan '26

16 Jan '26

==================================================================== OSSA-2026-001: Privilege Escalation via Identity Headers in External OAuth2 Tokens ==================================================================== :Date: January 15, 2026 :CVE: CVE-2026-22797 Affects ~~~~~~~ - Keystonemiddleware: >=10.0.0 <10.7.2, >=10.8.0 <10.9.1, >=10.10.0 <10.12.1 Description ~~~~~~~~~~~ Grzegorz Grasza with Red Hat reported a vulnerability in the external_oauth2_token middleware for keystonemiddleware. This middleware fails to sanitize incoming authentication headers before processing OAuth 2.0 tokens. By sending forged identity headers such as X-Is-Admin-Project, X-Roles, or X-User-Id, an authenticated attacker may escalate privileges or impersonate other users. All deployments using the external_oauth2_token middleware are affected. Patches ~~~~~~~ - https://review.opendev.org/973499 (2024.1/caracal) - https://review.opendev.org/973497 (2024.2/dalmatian) - https://review.opendev.org/973496 (2025.1/epoxy) - https://review.opendev.org/973495 (2025.2/flamingo) - https://review.opendev.org/973494 (2026.1/gazpacho) Credits ~~~~~~~ - Grzegorz Grasza from Red Hat (CVE-2026-22797) References ~~~~~~~~~~ - https://launchpad.net/bugs/2129018 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-22797 Notes ~~~~~ - The unmaintained/2024.1 branches will receive no new point releases, but patches for them are provided as a courtesy. - This bug was possible because the middleware only conditionally set certain headers (e.g., X-Is-Admin-Project was only set when the token had admin privileges), leaving spoofed values intact when conditions were not met. - The fix adds a call to remove_auth_headers() at the start of request processing to sanitize all incoming identity headers, matching the behavior of the main auth_token middleware. - The external_oauth2_token middleware was introduced in keystonemiddleware 10.0.0. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

2 2

Proposed 2026.2 "Hibiscus" release schedule
by Thierry Carrez 16 Jan '26

16 Jan '26

Hi everyone, Here is the proposed schedule for the 2026.2 "Hibiscus" release: https://review.opendev.org/c/openstack/releases/+/973377 For easier review, you can access the HTML rendering at: https://92fe49c75c4839534367-ca89416a8fe69de9445ee46610790deb.ssl.cf5.rackc… It's a 26-week-long cycle that places final release on Sep 30, 2026. Please comment on the review if you have objections to this or would like to make a case for targeting another week for the 2026.2 release. Thanks! -- Thierry Carrez (ttx)

1 0

[nova] does resize work with swap & no-swap flavor combo for image-backed server having vol attached
by tomergaurav1031＠gmail.com 16 Jan '26

16 Jan '26

Hi Team, I’ve encountered resize causing issues if source flavor has swap-disabled and target flavor have it enabled or vice-versa. It results into duplicate vdb error. Following are the steps:- 1 Create an image-backed(no volume attached) instance with flavor having swap disabled. 2 Create a volume and attach it with the instance (e.g. get attached at /dev/vdb). 3 Resize it to a bigger flavor which has swap & ephemeral enabled. 4 It results into error complaining about duplicate vdb:- libvirt.libvirtError: XML error: target 'vdb' duplicated for disk sources '/var/lib/nova/instances/1860acb4-012f-4528-b2ef-XXXXX/disk.swap' Should one not do resize with swap & no-swap flavor combo? Please provide thoughts/suggestions for the same. Thanks, Gaurav

3 4

[nova] [kolla-ansible ]help with nova image-cache cleaning interval
by garcetto 16 Jan '26

16 Jan '26

good morning, using kolla-ansible and trying to lower nova image-cache cleaning interval. I setup this value, but seems doing nothing despite the vms are deleted by far more than 600 secs, any help? where is a log of it? nano /etc/kolla/config/nova.conf " [image_cache] image_cache_manager_interval=600 remove_unused_base_images=true remove_unused_original_minimum_age_seconds=600 remove_unused_resized_minimum_age_seconds=600 " kolla-ansible -i multinode reconfigure --tags=nova thank you.

1 0

[neutron][ovn-bgp-agent] ovs bridges down causes error when configuring route table
by anas.jouhdy＠gmail.com 15 Jan '26

15 Jan '26

Hi, I am trying to use the OVN BGP agent (nb_ovn_bgp_driver with the exposing method underlay) and I would like to share a difficulty that I found, it might be related to the specific deployment that I have using Kayobe. I find that by default my openvswitch bridges appear to be down when I list them with "ip link". From what I saw in some forums this is a normal behaviour. The thing is that the OVN BGP agent uses ip link, for example here [1], to add route to a table link to these bridges and if there are down, this raise an error(pyroute2.netlink.exceptions.NetlinkError: (100, 'Network is down')). When I set the bridge state UP with "ip link" it solves the issue but this solution is not reboot persistent. Is it really a normal behaviour to have the openvswitch bridges down or is it a problem that I need to investigate on my configuration ? If this is a normal behaviour, anyone found a workaround that could be resilient in production (that is reboot persistent) ? Do not hesitate if you need more information on my configuration ! [1]: https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/ovn_bgp_agent…

2 1

[cinder] festival of reviews friday 2026-01-16
by Brian Rosmaita 14 Jan '26

14 Jan '26

Hello Argonauts, This is a reminder that the twice-monthly Cinder Festival of Reviews will be held at the end of this week on Friday 16 January. who: Everyone! what: The Cinder Festival of Reviews when: Friday 16 January 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

Upcoming metrics dashboard changes
by Ildiko Vancsa 14 Jan '26

14 Jan '26

Hi OpenStack community, Since the OpenInfra Foundation joined the Linux Foundation, we have been looking into opportunities to take advantage of the frameworks and tool sets that the Linux Foundation has, and some of you and your organizations are already familiar with. While the dashboards are still being built I would like to let you know that, as part of that effort, we will switch to LFX Insights[1] as the metrics dashboard for OpenInfra projects, including OpenStack, starting on __January 15, 2026.__ A couple things to note: - The new OpenStack metrics dashboard[2] is already available, but it is __still under active construction.__ - The set of metrics that is displayed on the new dashboard will not be identical with the metrics on the dashboard provided by Bitergia. - LFX Insights does not display affiliation information for individuals who are listed on the dashboard as contributors, for privacy reasons. However, if you already have an LF account[3], you will be able to check and update your affiliation information. Or, you can create a new LF account[4]. - You can learn more about the dashboard in the LFX Insights documentation[5]. - If your organization is an OpenInfra Foundation / Linux Foundation member already, the LF Organization Dashboard[6] is also available for a more company-centric view. The OpenStack Bitergia metrics dashboard[7] remains available __until January 14, 2026.__ Please let me know if you have any questions. Best Regards, Ildikö [1] https://insights.linuxfoundation.org/ [2] https://insights.linuxfoundation.org/project/OpenStack/ [3] https://openprofile.dev/ [4] https://docs.linuxfoundation.org/lfx/sso/create-an-account [5] https://insights.linuxfoundation.org/docs/introduction/what-is-insights/ [6] https://lfx.linuxfoundation.org/tools/organization-dashboard/ [7] https://openstack.biterg.io/ ——— Ildikó Váncsa Director of Community OpenInfra Foundation

4 7

[dev][ops][tc] Taking OpenStack to the Next Level in 2026
by Jeremy Stanley 13 Jan '26

13 Jan '26

At the informal OpenInfra Governing Board get-together in France immediately before the Summit, directors talked about how they might "drive projects to the next level." In a follow-up thread on the public board mailing listi[*], Julia posited: > If we perform a risk assessment ourselves, what social and > technical aspects would come to mind? How can we move those items > forward? This was delegated to the foundation staff, whose executive management chose it as one of our three goals[**] for 2026: "Elevate OpenInfra projects to their next level" To this end, community managers and other staff have collaborated to draft areas of focus for ourselves with associated success measurements relevant to each OpenInfra Project. In the case of OpenStack, this is what we came up with: "Lowering the barriers to participate in OpenStack through clear and visible avenues and forums to get involved and collaborate, increased reviewer bandwidth and efficiency, and simplified user survey." The idea is that the foundation staff, through a multi-pronged approach, can coordinate a number of initiatives we've got underway for the year such as closer collaboration between operator-oriented groups and SIGs, continuation of the Bridging the Gap effort, planned improvements to www.openstack.org content, and giving the User Survey a much needed tune-up. Efficacy will be determined in various ways including impact on code review response times, sharing/adoption of more efficient communication behaviors across teams, cross-pollination in operator activities, increased feedback from surveys, and more effective reliance on relevant sections of the website. I'm bringing this draft plan to the mailing list to solicit community feedback, in preparation for an upcoming presentation to the board of directors. Keep in mind that the point of this exercise is to better use my time and the time of my colleagues on the staff of the OpenInfra Foundation in service of OpenStack, not to make more work for leaders and project maintainers nor to set technical direction as that's not our place. I just want to make sure that this plan is sensible and doesn't conflict with community expectations, while putting our limited resources into the right activities. If anyone has concerns or improvements to suggest please feel free to follow up in this thread or voice them to me directly (ideally over the coming week), or to your representatives on the OpenInfra Governing Board (who will be the ones to ultimately approve what we come up with). As always, thanks for everything you do in the name of OpenStack! [*] https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.… [**] https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… -- Jeremy Stanley

1 0

[openstack-ansible] : Galera DB backup on Epoxy release
by keshav bareja 13 Jan '26

13 Jan '26

Hi Team We have recently upgraded to the Openstack-ansible Epoxy [2025.1] release. In this release Galera mariadb is upgraded to MariaDB 11.4.8. We have a daily DB backup crontab setup for the backup and before the Epoxy release we were using the below command to take the backup and now it doesn't work anymore. mysqldump --opt --all-databases > "openstack_$(date +'%Y-%m-%d_%H-%M-%S').sql" Can you please recommend the way to take the Galera DB backup now? I can see the command mariadb-dump, can we use the options below? mariadb-dump \ --all-databases \ --single-transaction \ --quick \ --skip-lock-tables \ --skip-add-locks \ --routines \ --events \ --triggers \ > "openstack_$(date +'%Y-%m-%d_%H-%M-%S').sql" Regards Keshav

2 3