OpenStack Cinder CSI 2.36.1 - Chart Verification Notes

OpenStack Cinder CSI openstack-cinder-csi-2.36.1 was published on July 29, 2026. The release delivers the Cinder CSI chart for OpenStack, but the upstream note does not identify fixes, template changes, dependency updates, or migration steps. For operators, the chart artifact is the important change, not any undocumented claim about driver behavior.

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

The published note says only “Cinder CSI Chart for OpenStack.” The metadata identifies the exact tag as openstack-cinder-csi-2.36.1 and marks it as a final release, not a prerelease. That is the complete public change record attached to this release.

No pull requests, commit hashes, chart value names, image versions, compatibility bounds, fixes, or security changes are listed. There is also no stated migration procedure. The notes therefore do not support claims about controller behavior, Cinder API handling, Kubernetes compatibility, or changed chart defaults.

This distinction matters when release automation treats every new tag as a candidate for immediate rollout. A version number proves that an artifact was published. It does not explain the rendered manifest delta or the effect on a running storage path.

Cinder CSI sits on the persistence path for workloads that use OpenStack block storage. ETL workers, databases, queues, and staging jobs can all depend on volumes provisioned through that path. A chart rollout can affect those consumers if its rendered resources or image references differ, even when the release note gives no detail.

The practical risk is not the tag by itself. It is an unreviewed change to the Kubernetes objects that deploy and authorize the storage components. Chart templates can describe workloads, service accounts, RBAC, configuration, secrets, scheduling rules, probes, and container images. The release notes do not say which, if any, of those areas changed in 2.36.1.

Likewise, the absence of a breaking change notice is not evidence that every existing values file will render the same output. Operators should treat this as an evidence gap and inspect the candidate artifact before promotion.

Start with a manifest comparison using the exact values supplied to the currently deployed chart. Keep the chart version, input values, Helm version, and rendered output in the deployment record so the review can be reproduced.

  • Compare every rendered Kubernetes object, not only the controller and node workloads.

  • Review container image references, arguments, probes, resource settings, node placement, RBAC, and secret references.

  • Run a test that provisions a volume, mounts it, writes data, restarts the consuming pod, and verifies the data before deleting the test claim.

  • Test expansion or snapshot operations when production pipelines depend on those capabilities.

  • Confirm that rollback uses the previous chart artifact and values together. Reusing new values with an old chart can produce a different manifest from the known deployment.

These checks do not assume that 2.36.1 changes any particular template. They establish whether it does, which is the information missing from the published note. The release page should remain attached to the change record as the upstream source.