kubernetes/cloud-provider-openstack Manila CSI 2.36.3 Helm Chart Release

The kubernetes/cloud-provider-openstack repository released version openstack-manila-csi-2.36.3 on September 7, 2026. This release provides updated Helm chart packaging for the Manila Container Storage Interface driver across Kubernetes clusters running on OpenStack infrastructure. The release is an official stable build rather than a prerelease candidate.

The full release notes and downloads are on the GitHub release page.

The openstack-manila-csi-2.36.3 release focuses on the Helm chart distribution for the Manila Container Storage Interface plugin. OpenStack Manila gives tenant workloads access to shared file system storage, such as NFS exports or CephFS volumes. In Kubernetes environments, the Manila CSI driver translates standard storage requests into Manila API operations, enabling dynamic provisioning of shared persistent volumes.

Packaging the Manila CSI driver as a dedicated Helm chart standardizes installation and lifecycle management. Platform operators can use the chart to deploy necessary cluster components, including the CSI controller plugin, node plugin DaemonSets, custom resource definitions, and RBAC authorization roles. Tagging chart updates independently under openstack-manila-csi-2.36.3 ensures that storage infrastructure manifest updates remain explicit and predictable across deployment pipelines.

Distributed data processing frameworks operating on Kubernetes frequently require shared storage access across multiple worker nodes. Runtimes executing file ingestion, batch analytics, or model training often rely on ReadWriteMany access modes to process common data directories simultaneously. The Manila CSI driver enables Kubernetes pods to attach shared OpenStack file systems directly into container paths without manual storage configuration.

By updating the Manila CSI Helm chart, platform engineering teams maintain alignment between storage provisioner manifests and underlying cloud infrastructure APIs. The Helm chart defines parameter schemas for storage classes, controlling how access rules, share types, and export locations are configured during volume creation. Standardized chart templates allow platform teams to automate storage provisioning across development, staging, and production environments while preventing drift in cluster configuration.

The kubernetes/cloud-provider-openstack repository hosts multiple distinct components required for OpenStack cloud integration, including the OpenStack Cloud Controller Manager, Cinder CSI driver, and Manila CSI driver. Operating each storage driver with dedicated release tags like openstack-manila-csi-2.36.3 provides modular version control for infrastructure operators.

This release isolation allows teams to update the Manila CSI Helm chart without modifying other cloud provider components or updating the Kubernetes control plane core binaries. Infrastructure teams can test Manila storage chart updates independently in isolated staging clusters, validating shared file system mounts before rolling updates out to broader production clusters. Decoupled chart versions also streamline rollbacks if specific OpenStack cloud API behaviors require pinned chart configurations.

Upgrading to the openstack-manila-csi-2.36.3 Helm chart requires verifying cluster parameters and OpenStack tenant credentials. Infrastructure operators should review custom values files used during chart installation to ensure compatibility with existing cluster configurations.

First, inspect the target values file to verify container image registries, image pull policies, and resource requests for Manila CSI controller and node pods. Second, verify that the cloud-config secret contains valid OpenStack Keystone authentication parameters and Manila endpoint URLs. Third, execute a dry run upgrade using helm upgrade --dry-run to validate generated Kubernetes manifests before applying changes to the cluster. Finally, monitor node DaemonSet rollouts and test ReadWriteMany volume mounting on sample workloads to ensure operational stability.