OpenStack Manila CSI 2.36.2 - Sparse Chart Release Notes

OpenStack Manila CSI openstack-manila-csi-2.36.2 was published on July 29, 2026. The release publishes the Manila CSI chart for OpenStack, but the notes do not identify any chart, controller, node service, or dependency change. For operators, that missing change detail is the most important fact about this version.

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

The complete GitHub note is one sentence: “Manila CSI Chart for OpenStack.” The release metadata identifies the repository, the exact tag, and the publication time. It also marks 2.36.2 as a final release, not a prerelease.

No change list accompanies that description. There are no fixed issue references, pull request links, commit references, image versions, chart dependency versions, compatibility bounds, or migration steps. The notes also contain no security advisory and no claim of a bug fix.

That leaves no defensible set of three to five implementation changes to summarize. Calling 2.36.2 a packaging update, a behavior change, a compatibility release, or a security fix would add facts that the source does not provide. This is a versioned chart publication with an undisclosed delta.

Operators can pin the exact tag and record its publication at 2026-07-29T15:40:18Z. They can also establish that this is not an alpha, beta, or release candidate. Those facts are sufficient for artifact tracking, but not for a production upgrade decision.

The empty change record does not mean the release has no behavioral changes. It does not establish compatibility with any Kubernetes or OpenStack version, either. No chart setting, command flag, manifest path, controller behavior, or node behavior is named in the notes, so there is no field specific migration advice to apply.

That distinction matters for data platforms using Manila backed volumes for batch jobs, staging areas, shared datasets, or stateful processing. A chart revision can affect storage workloads even when the release page does not explain the delta. The release page alone cannot establish the likely blast radius.

Keep observed evidence separate from assumptions during review. Record the exact tag and timestamp first. Then compare the rendered manifests for 2.36.2 with the version currently approved in the target environment. Review any differences in container images, RBAC rules, process arguments, resource requests, scheduling constraints, volumes, and generated objects. These are validation targets, not claimed changes in 2.36.2.

Run provisioning, mount, write, read, unmount, and deletion checks against the same Manila service and Kubernetes version used in production. Include a workload that exercises the access mode and share type expected by the data platform. Retain the previous chart reference as a rollback point until those checks pass.

If the rendered output is unchanged, record that result in the change ticket. If it differs, the manifest diff becomes the practical change record that this release page does not supply. Teams that require traceability may reasonably hold promotion until that review is complete.