OpenStack Manila CSI 2.36.1 - Chart Operator Review

OpenStack Manila CSI 2.36.1, tagged openstack-manila-csi-2.36.1, was published on July 29, 2026. The release publishes the Manila CSI chart for OpenStack, which is the only change identified by the notes. It is not a prerelease, but the page gives operators no change list or migration guidance.

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

The release note is one line: “Manila CSI Chart for OpenStack.” It confirms the component and packaging scope. It does not list bug fixes, dependency updates, container image changes, chart default changes, compatibility statements, or security fixes.

That limit matters in a repository whose release tag names a specific component. The supported conclusion is narrow: this release concerns the Manila CSI chart. Nothing on the page supports extending its scope to another OpenStack integration or treating it as a general repository release.

The notes also provide no mapping from the tag to container images, Kubernetes versions, OpenStack versions, or Helm dependencies. They name no configuration keys or file paths. As a result, there are no specific new settings that can be recommended from the published material alone.

For platform teams running stateful data services, the chart is deployment input. A change in rendered resources can affect controller placement, node access, credentials, mount behavior, or recovery even when the release description says nothing about those areas. That is a reason to inspect the artifact, not evidence that any of those behaviors changed in 2.36.1.

Before rollout, compare the currently deployed output with output rendered from the candidate chart. Keep the review tied to observable differences:

  • Compare workload specifications, service accounts, roles, bindings, volumes, and security contexts.

  • Record container image references, command arguments, resource requests, node selectors, tolerations, and probe settings.

  • Run the existing CSI smoke path for provisioning, pod mount, pod restart, unmount, and deletion against a disposable dataset.

  • Preserve the current values and rendered manifests so rollback does not depend on reconstructing prior configuration during an incident.

The release page does not identify any of these fields as changed. This checklist closes the documentation gap without turning assumptions into release facts.

No breaking changes or migration steps are documented. That absence is not a compatibility guarantee. It only means the published notes provide no warning about either category.

The metadata marks the release as final rather than a prerelease. Operators can therefore evaluate it as a normal upgrade candidate for their own environments, while still requiring the same staged checks used for any storage control plane change. Start in a noncritical workload group, observe controller and node logs during the CSI lifecycle test, and retain the previous deployment inputs until the test completes.

The practical constraint is traceability. Record the exact tag, the rendered manifest diff, the test result, and the rollback reference in the change ticket. If the diff is empty, the release may be packaging only from the operator perspective. If it is not empty, the diff is the available change record because the release notes do not supply one.