April 2026 - openstack-discuss - lists.openstack.org

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

24 Apr '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 8

[kolla] Removal of pre-Zed Kolla images from quay.io on June 1st, 2026
by Michał Nasiadka 23 Apr '26

23 Apr '26

Hi Koalas, This is a notice that all pre-Zed release Kolla container images hosted in the quay.io/openstack.kolla organisation will be permanently removed on **June 1st, 2026**. If you are still relying on any of these older image tags, please plan your migration to a supported release before that date. --- **Reminder: These images are intended for testing purposes only.** As documented in the Kolla README [1], the Kolla team does not perform security vulnerability remediation or hardening on the published images. They should **not** be used in production environments. If your deployment requires security-hardened container images, please refer to your OpenStack distribution vendor or build your own images using the Kolla tooling. --- Timeline summary: - **Affected:** All image tags predating the Zed release in quay.io/openstack.kolla - **Removal date:** June 1st, 2026 - **Action required:** Migrate to a supported release before the removal date If you have any questions or concerns, please feel free to reply to this thread or reach out on the #openstack-kolla OFTC IRC channel. Thank you, Michal --- [1] https://opendev.org/openstack/kolla/src/commit/4a7e5ee0dd0fe3ea31a3e6d59a51…

1 0

[all][qa] The hacky way to do early python 3.14 tempest testing
by Sean Mooney 23 Apr '26

23 Apr '26

Hi all o/ So I have been experimenting with optionally supporting uv in DevStack to provide a portable (cross-distro) way to provide Python interpreters without building them from source and an alternative to pip (using uv pip) to create and install dependencies in the testing venv. I am not entirely happy with how the series is currently proposed, as I got AI to take the working commit and break it down into smaller commits, so I will probably change that in the future, but the important thing is it works end to end. One of the decisions I made in the series was to support having uv provide the interpreter and disabling --site-packages when creating the venvs. That means the DevStack venvs are isolated from the host Python. https://review.opendev.org/c/openstack/devstack/+/985735 is a DNM that turns on this functionality and pins Python to 3.14. Several jobs have passed: https://zuul.opendev.org/t/openstack/buildset/da24501f7c384e448209691fa86eb… Many failed on a semi-known pickle issue that breaks Nova's noVNC proxy, but several of the passing jobs are non-trivial. You can see that tempest-multinode-full-py3 passed: https://zuul.opendev.org/t/openstack/build/e3442f47e9914be1b7508f8193fc841e While that is not the same as all Tempest tests passing, it is a pretty wide cross-section of OpenStack. For example, not only those that boot and migrate VMs, but it attaches and detaches volumes and instances, including booting from multi-attach Cinder volumes and then resizing. swift-dsvm-functional also passed under Python 3.14. If you are interested in getting a smoke test for your projects just to get a baseline of what is and is not functional, I would suggest creating a DNM patch like this: https://review.opendev.org/c/openstack/nova/+/985802 Hopefully we will be able to do more standard testing with Python 3.14 once Ubuntu 26.04 is available, but I just wanted to share this in the interim. regards sean

2 1

[cinder][PTG] 2026.2 Hibiscus PTG summary
by Jon Bernard 23 Apr '26

23 Apr '26

Hello everyone, thanks for a very productive PTG for the Hibiscus cycle. Below is a brief summary of the highlights. The summary and transcribed etherpad[^1] notes are captured on our wiki[^2]. # Cinder 2026.2 Hibiscus PTG Summary **Date:** April 20–24, 2026 (Virtual) --- ## 2026.1 Gazpacho Retrospective - Every release deadline was missed by a few days (including client libraries and os-brick). - Agreement to be stricter about release deadlines and send explicit deadline reminders. - No concrete solution yet for prioritizing reviews to ease deadline pressure. --- ## 2026.2 Release Planning - Discussion of adding Cinder-specific entries to the Hibiscus release schedule. - Contributor documentation needs updating: deliverables list, meeting cadence (resume monthly video meeting), and explicit os-brick readiness dates. - Add a "new driver declaration deadline" early in the cycle to allow time for review planning. - **Action:** agalica to review contributor docs for clarity and correctness. - **Action:** jbernard to consider moving the review festival to a single block after the weekly meeting. --- ## Scheduler Sending Jobs to Disabled Hosts (zigo) - Patch under review: [!979641](https://review.opendev.org/c/openstack/cinder/+/979641). - Reviewers need a bug filed with more detail to understand the fix; a possible race condition is suspected. - Patch needs unit tests. The question of whether "frozen" hosts are also affected needs investigation. --- ## Supply WWID Instead of LUN Numbers (rajat) - Current iSCSI/FC logic uses LUN numbers, which can change or overlap under certain conditions. - Proposal: use WWID (which is stable for the lifetime of a LUN) instead, with LUN-based code kept as a fallback. - Drivers will need updates; strategy is to start with the LVM driver (LIO target) for iSCSI. - A tempest test should be added to enforce the new contract, with a grace period of a couple of cycles for vendor CIs. - **Action:** rajat to send a message to the mailing list for vendor feedback. --- ## New Driver Status (erlon) Three new drivers are currently in review for Hibiscus: - ZTE: [!969207](https://review.opendev.org/c/openstack/cinder/+/969207) - LINSTOR: [!964289](https://review.opendev.org/c/openstack/cinder/+/964289) - HPE Alletra MP: [!969373](https://review.opendev.org/c/openstack/cinder/+/969373) Goal is to compile a driver list early in the cycle to direct review resources appropriately. --- ## RBD Encryption Performance (rsasitilak) - Proposal to use the librbd engine to bypass the QEMU single-thread bottleneck during encrypted volume I/O. - Skepticism about the performance improvement claims and the level of rework required to the current RBD implementation. - **Action:** jbernard to respond to the [mailing list thread](https://lists.openstack.org/archives/list/openstack-discuss@lists.o… requesting more detailed benchmarking information. --- ## Volume Migration with Snapshots (fqi) - Currently, migrating a volume that has snapshots fails. - Proposal to query drivers for available functionality and use it when present, broken into three stages. - Blueprint: [volume-migration-with-snapshot](https://blueprints.launchpad.net/cinder/+sp… - Open questions remain around snapshot semantics (snapshots becoming separate volumes) and vendor-specific COW implementations. --- ## HPE Alletra MP Driver (Jyotsna/raghavendrat) - New driver in review: [!969373](https://review.opendev.org/c/openstack/cinder/+/969373). - Uses the `hpe-storage-flowkit-py` library as an intermediary layer to separate backend-specific logic from driver code. --- ## Backup Container Name Templates (noonedeadpunk) - Spec: [!962306](https://review.opendev.org/c/openstack/cinder-specs/+/962306); patch: [!962909](https://review.opendev.org/c/openstack/cinder/+/962909). - Key concern: when the template changes in config, operators must manually migrate existing backup data. - Discussion of adding a DB field to track the actual (post-template) container name separately from the configured value. --- ## CBT-Based Incremental Backup (hong-p) - Spec: [!985089](https://review.opendev.org/c/openstack/cinder-specs/+/985089). - Proposal to optimize incremental backups using Changed Block Tracking (CBT). - Nova involvement required for attached volumes; Cinder implementation useful for bare-metal attachments. - No philosophical objections from the team; free to proceed. Open questions include where to store CBT data and the need for an external REST API. --- ## Logging Guidelines (Anoop_Shukla / NetApp) - Proposal for a dedicated logging best-practices document for Cinder driver authors, covering log level definitions and usage of the `(a)volume_utils.trace` decorator. - Working document: [OpenStack Cinder Logging Guidelines etherpad](https://etherpad.opendev.org/p/OpenStack_Cinder_Logging_Guideline…. - Seeking community feedback. --- ## RBD Performance: Direct Import (ricolin) - Using QEMU to output directly rather than `rbd import` yields at least a 20% I/O performance improvement for large (>1 TB) volumes, including encrypted volumes. - Relevant patches: - Non-encrypted: [!972263](https://review.opendev.org/c/openstack/cinder/+/972263) - Encrypted (direct import): [!933006](https://review.opendev.org/c/openstack/cinder/+/933006) - Encrypted (direct volume creation): [!910700](https://review.opendev.org/c/openstack/cinder/+/910700) - Alternative encrypted approach (rajat): [!955273](https://review.opendev.org/c/openstack/cinder/+/955273) --- ## Replication v3 (rajat) - Spec: [!985952](https://review.opendev.org/c/openstack/cinder-specs/+/985952). - Extends replication to support finer-grained failover (per-volume, per-pool, per-backend). - Includes automation of failover for synchronous replication and cross-cluster failover with security guards. - Safeguards needed to prevent overlap between replication granularities. --- ## 3rd-Party CI Systems (simondodsley) - Current tooling (SoftwareFactory moving to OpenShift) is not sustainable for all vendors. - Proposal to create a standard, simple CI template for running Cinder and os-brick tests, reporting to Gerrit, and storing logs in a GitHub repository with a standard URL format. --- ## NetApp Topics (jayanan) - Per-pool image cache enhancements. - Replication over Fibre Channel. - Best practices for raising dependent patches (noted: `git-restack` tool). - ONTAP REST vs. ZAPI migration gaps. --- ## Friday Patch Review - General patch review session. - Kubernetes lock support patch flagged for attention: [!956528](https://review.opendev.org/c/openstack/cinder/+/956528). [^1]: https://etherpad.opendev.org/p/cinder-hibiscus-ptg [^2]: https://wiki.openstack.org/wiki/CinderHibiscusPTGSummary

1 0

OSSN-0095: OVN security group rules created before address group support may be ineffective
by Goutham Pacha Ravi 23 Apr '26

23 Apr '26

OSSN-0095: OVN security group rules created before address group support may be ineffective == Summary == In deployments using the OVN ML2 driver, security group rules referencing remote address groups that were created before OVN address group support was added do not enforce source address filtering. The resulting OVN ACLs allow traffic from any source to the destination port. == Affected Services / Software == * neutron (OVN ML2 driver): <25.2.3, >=26.0.0 <26.0.3, >=27.0.0 <27.0.2 == Discussion == Before OVN address group support was added, the Neutron API accepted address group references in security group rules without error, but the OVN driver silently ignored them. The resulting ACLs had no source address set, effectively allowing 0.0.0.0/0. After upgrading, new rules work correctly but pre-existing ones are not fixed. The neutron-ovn-db-sync-util repair mode also does not correct them. Deleting an affected rule via the API orphans the ACL in OVN, which continues to pass traffic. A fix has been merged that adds a maintenance task to automatically create missing address sets and update affected ACLs on service restart. == Recommended Actions == Upgrade to a version of neutron containing the fix ([https://review.opendev.org/c/openstack/neutron/+/976832 Gerrit 976832]) and restart the neutron services. The maintenance task will correct pre-existing rules automatically. Operators should verify that orphaned ACLs from previously deleted rules are removed. == Credits == James Denton, Rackspace == Contacts / References == o * Authors: Goutham Pacha Ravi, Red Hat * This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0095 * Original Launchpad bug: [https://launchpad.net/bugs/2141589 LP#2141589] * Mailing List: [security-sig] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security: https://security.openstack.org/ * CVE: none

1 0

[cyborg] delete left-over devices
by Jiatong Shen 23 Apr '26

23 Apr '26

Hello Team, We have several GPU devices for virtualization and want to switch some of them to be baremetal. We use cyborg to manage GPU resources. Before move the compute node out of the cluster, we forgot to reconfigure the cyborg agent and remove corresponding devices. My question is is there any command to remove cyborg device manually? I tried something like "openstack accelerator device remove", but seems it does not exist. Then openstack we are using is victoria. -- Best Regards, Jiatong Shen

2 2

[magnum] PTG summary
by Michał Nasiadka 22 Apr '26

22 Apr '26

Hello, This is a summary of the Magnum PTG sessions that we had on Monday (EMEA+US slot, attendance: 12) and Tuesday (EMEA+APAC slot, attendance: 4) Driver Guidance and Strategy Driver Landscape: The community present on the sessions continues to state that Magnum should act as a wrapper for third-party drivers rather than having an "official" internal one (to be state, currently there’s the Heat based driver that is deprecated and subject to removal) Driver Comparison: magnum-cluster-api (MCAPI): Actively supported and developed by Vexxhost. magnum-capi-helm: No activity since Dec 2025 with majority of the core team behind it inactive. Long-term Goal: The community intends to work towards having bothmagnum-capi-helm andmagnum-cluster-apirunning both drivers simultaneously on a single installation, to allow migration and to allow users to explore both drivers. Project Health and Maintenance Developer Support: While the team is small, at least two organizations are actively supporting the project. New reviewers are being onboarded (Rico Lin@VexxHost is one of the volunteers). Communication: The team agreed to hold a regular meeting at 13:00 UTC (every two weeks). Community will be also present on Kubernetes Slack (channel #openstack-magnum) in addition to #openstack-containers on OFTC to increase community reach. User Feedback: A question regarding driver usage will be added to the next OpenStack User Survey to better understand the deployer landscape. Technical Infrastructure and CI CI Improvements: There is a strong push to implement Zuul based CI for both drivers. Resource Allocation: The team will experiment with ubuntu-noble-32GB labels in Zuul (which support nested virtualization) to run Devstack (with devstack-plugin-container) and Sonobuoy smoke tests. Eventlet Migration: Work is underway to migrate away from Eventlet, but progress depends on getting the CI stable enough to validate the changes. Removing Tech Debt: There is also work underway to remove years of tech debt in usage of deprecated Oslo libraries functions and other similar methods/libraries API and Image Management Microversions: Discussion focused on using microversions for Magnum API versioning and API extensions to replace the existing labels that are being used. Image Publishing: To simplify deployments, the project will point users toward Vexxhost’s capo-image-elements for building and obtaining cluster images. Driver Pain Points magnum-capi-helm: Issues were noted regarding "blind spots" during status reporting (clusters getting stuck without feedback), lack of support for unique nodegroup labels, and risks associated with cluster upgrades across incompatible templates. With the lack of activity in that driver’s code space - the community will need to reassess if the driver can continue under the project’s governance. Security & Architecture: magnum-cluster-api issues with direct communication between magnum-conductor and workload clusters has been raised (and the overall documented architecture - both network and security wise). There is some documentation in OpenStack Ansible (OSA) that could be used as a starting point of that documentation efforts in magnum-core and/or magnum-cluster-api. There is also potential in future rework of magnum-cluster-api proxy architecture utilizing Cluster API runtime SDKs and remote tunnels instead. Thank you for all attendees, for additional content please see the etherpad [1]. [1]: https://etherpad.opendev.org/p/apr2026-ptg-magnum Cheers, Michal

1 0

[barbican] Review request: 5 small bugfixes / cleanups (LP #2147221 et al.)
by Joshua Cornutt 22 Apr '26

22 Apr '26

Hi all, I have five small Barbican changes sitting in Gerrit since April 3 with Zuul +1 and no human review yet. Would appreciate eyes from anyone with bandwidth. I'm happy to rebase, split, or rework any of them based on feedback. Bug fixes: 983320 Allow EC curve bit lengths in order validation https://review.opendev.org/c/openstack/barbican/+/983320 Fixes LP #2147221 - TypeOrderValidator._validate_bit_length rejects P-521 (521 bits) because it enforces a multiple-of-8 rule that does not apply to EC curves. P-256 and P-384 happen to pass; P-521 is blocked. Adds an EC-aware exemption for the standard curve bit lengths. https://bugs.launchpad.net/barbican/+bug/2147221 983328 Fix SimpleCryptoPlugin TypeError when kek is unconfigured https://review.opendev.org/c/openstack/barbican/+/983328 Replaces an opaque TypeError with a clear configuration error when the simple_crypto_plugin kek option is missing. 983290 Fix incorrect P11CryptoPluginException import in KEK migration script https://review.opendev.org/c/openstack/barbican/+/983290 The script references an exception class from the wrong module, so the error path crashes instead of reporting. Docs / cleanup: 983319 Add note about enforce_new_defaults runtime override https://review.opendev.org/c/openstack/barbican/+/983319 983331 Remove deprecated pkcs11-key-generation script https://review.opendev.org/c/openstack/barbican/+/983331 All target master, all patchset 1, all Zuul Verified+1. Each is independent with no stacking. Thanks, Joshua Cornutt (jcornutt on Gerrit / OFTC) Open Edge Cloud

1 0

[neutron] neutron-l2gw needs a Gazapcho release
by Thomas Goirand 22 Apr '26

22 Apr '26

Hi, Building neutron-l2gw 21.0.0 with the rest of gazpacho leads to unit tests turning in loop for hours. I packaged 21.0.0+git.2026.04.09.c548b75828 (ie: tip of master), and it works a way better. So I'm hereby requesting that a Gazpacho release is tagged. Cheers, Thomas Goirand (zigo)

3 3

[swift][ptg] Ops Feedback Session - 22nd April at 1300 UTC
by Matthew Oliver 21 Apr '26

21 Apr '26

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the hibiscus swift meetpad room ( https://meetpad.opendev.org/p/apr2026-ptg-swift) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-hibiscus-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0