# Storage Automation Comes to OpenStack **Author:** Bala Ramesh **Published:** October 6, 2026 ![Monochrome data center with server racks and glowing lines representing data flow.](https://cdn.sanity.io/images/ult5g8gw/production/9a7de0a49cd8642856ae98707679a11119ca42e6-1408x768.jpg) ## TL;DR Automate shared storage through OpenStack’s native workflows with WEKA’s in-tree Manila driver. - Provision filesystems through the Manila API, CLI, or Horizon. - Manage snapshots, resizing, and existing WEKA filesystem imports. - Eliminate separate driver installs, repositories, and version tracking. Infrastructure orchestration teams automate everything. Compute is provisioned from templates. Networks are declared in code. GPU nodes are added to clusters through infrastructure-as-code workflows. Upgrades roll through the environment. Failed resources are automatically reconciled. Infrastructure is defined in a repository and deployed programmatically. Storage is often the one component left out of the infrastructure automation equation. It’s provisioned and configured through separate tools, with its own operational workflows and lifecycle management. For teams running infrastructure across multiple clusters, clouds, or data centers, those separate processes have to be built, maintained, and repeated for every environment. ## Meet Teams in the Tools They Already Use Our approach is to make storage part of the infrastructure automation model teams already use. That means integrating with the core platforms responsible for provisioning, scheduling, and managing the rest of the environment rather than introducing a separate operational workflow for storage. We’ve been working with some of the largest AI and HPC infrastructure deployments to integrate WEKA® NeuralMesh™ into the orchestration frameworks they already depend on, including Kubernetes, Terraform in the public cloud, and Slurm in HPC environments. The goal is consistent across each: make storage deployable and manageable through the automation infrastructure teams already operate. With the latest OpenStack [Hibiscus release](https://www.openstack.org/software/openstack-hibiscus), that approach now extends to OpenStack. ## WEKA NeuralMesh Is Now Part of OpenStack The [OpenStack Hibiscus release](https://www.openstack.org/software/openstack-hibiscus) became generally available Sept. 30 and includes [WEKA’s Manila driver](https://github.com/openstack/manila/tree/master/manila/share/drivers) in-tree. This means operators can take the Hibiscus release from their distribution of choice and WEKA NeuralMesh is already included. There’s no separate driver to download, no vendor repository to add, and no additional driver version to track against the platform’s release cadence. The code is reviewed and maintained under the OpenStack project’s governance, like the rest of the release. Operators can provision shared filesystems through native OpenStack workflows: openstack share create, the Manila API, or Horizon. Each Manila share is backed by a dedicated WEKA filesystem, with support for snapshots, resizing, and importing existing WEKA filesystems into Manila management. Multiple virtual machines and containers can access the same filesystem concurrently, providing the shared data access required by AI training and containerized data pipelines. ## Storage as Code Across the Infrastructure Stack OpenStack is the newest addition to a broader set of integrations designed to make the data layer part of the infrastructure automation stack. Today, that approach spans four key environments: 1. OpenStack: The new in-tree [WEKA Manila driver](https://github.com/openstack/manila/tree/master/manila/share/drivers) lets operators provision and manage shared filesystems through native OpenStack workflows, including the Manila API, CLI, and Horizon. 2. Kubernetes: The [WEKA Kubernetes Operator](/resource/weka-kubernetes-operator) manages the storage cluster lifecycle through Kubernetes, including deployment, scaling, upgrades, and reconciliation. For container workloads, csi-wekafs provisions persistent volumes through Kubernetes PersistentVolumeClaims (PVCs). 3. Slurm on Kubernetes: In HPC and AI environments, WEKA NeuralMesh coordinates CPU allocation with Kubernetes and Slurm so the storage data path and scheduled compute workloads don’t compete for the same CPU resources. This work grew out of our collaboration with CoreWeave on [SUNK](https://docs.weka.io/best-practice-guides/weka-and-slurm-integration/configure-kubernetes-and-weka-for-coreweave-sunk). 4. Terraform: In the public cloud, WEKA NeuralMesh provides Terraform modules for declarative cluster provisioning, allowing storage infrastructure to be defined and deployed through the same infrastructure-as-code workflows as compute and networking. These integrations serve different control planes: Kubernetes workloads request volumes through CSI and PVCs, while OpenStack operators provision shared filesystems through Manila for clients that can include VMs, containers, and bare-metal systems. ## When Every Environment Is Different That becomes especially important for infrastructure providers operating across multiple environments. [Andromeda](https://andromeda.ai/) connects AI teams to compute across more than 50 providers worldwide. They stress consistency: every cluster is certified across GPU, storage, network fabric, and security before a customer touches it, regardless of who owns the hardware underneath. Storage was the hard part. Each provider arrived with its own storage environment, and performance varied from cluster to cluster. That’s a problem when uniform quality is what you’re selling. [Andromeda standardized on WEKA NeuralMesh](/pressRelease/weka-and-andromeda-partner-to-power-ai-workloads-at-global-scale) as the data layer across that fleet. Its NeuralMesh Axon™ clusters sustain more than 400 GB/s per cluster and 6 million IOPS in production, and new clusters deploy in minutes on hardware that was already there. ## Storage Shouldn’t Be the Exception No two infrastructure environments look alike, and none of them were built around the requirements of a storage vendor. Some teams run OpenStack for private cloud infrastructure. Others use Kubernetes to orchestrate containerized AI environments, Slurm to schedule HPC and AI workloads, or Terraform to provision infrastructure across the public clouds. Many use several of these technologies together. The goal isn’t to force those environments into a common operating model. It’s to make the data layer native to the operating model that’s already there. Using OpenStack? [Download the Hibiscus release](https://releases.openstack.org/hibiscus/index.html) from your distribution of choice. The [WEKA Manila driver](https://github.com/openstack/manila/tree/master/manila/share/drivers) is already there. No separate install. No vendor repository. And no extra version to track alongside everything else you maintain.